zamiacad-devel — zamia developer's mailing list

Re: [Zamiacad-devel] VHDL 2008 Support

[Walter G. <wal...@ve...>]

Hi Guenter,

My concerns is about verification techniques support as OSVM and others 
not a full VHDL 2008 version.

Best regards

Walter


El 04/01/18 a las 19:51, Guenter Bartsch escribió:
> Hi Walter,
>
> On Wed, Jan 3, 2018 at 2:21 AM, Walter Gallegos
> <wal...@ve...> wrote:
>
>>  From docs ZamiaCAD support VHDL 2003 have you plans to support VHDL 2008 ?
> ZamiaCAD should support some 2008 features but support is not
> complete. I am not aware of any plans to add more 2008 features right
> now.
>
> best,
>
>     guenter
>

Re: [Zamiacad-devel] VHDL 2008 Support

[Guenter B. <gue...@gm...>]

Hi Walter,

On Wed, Jan 3, 2018 at 2:21 AM, Walter Gallegos
<wal...@ve...> wrote:

> From docs ZamiaCAD support VHDL 2003 have you plans to support VHDL 2008 ?

ZamiaCAD should support some 2008 features but support is not
complete. I am not aware of any plans to add more 2008 features right
now.

best,

   guenter

[Zamiacad-devel] VHDL 2008 Support

[Walter G. <wal...@ve...>]

Hi,

 From docs ZamiaCAD support VHDL 2003 have you plans to support VHDL 2008 ?

Best regards

Walter

Re: [Zamiacad-devel] Secret of ZamiaCAD scalability

[Guenter B. <gue...@gm...>]

Hi Valentin,

On Fri, Oct 31, 2014 at 8:09 PM, Valentin Tihomirov
<val...@gm...> wrote:
> There was a lot of hype around unique Zamia scalability but its proponents
> could never expose the secret. Now, I decided to expand Zamia with EDIF
> export and suddenly discovered that design
>
> module DUT
>   G1: module AND2
>   G2: module AND2
>
> has an interesting IG structure,
>
>   path=DUT, structure.getPath()= WORK.TB:DUT
>   path=DUT.G2, structure.getPath()= WORK.TB:DUT.G1
>   path=DUT.G1, structure.getPath()= WORK.TB:DUT.G1
>
> It is obtained using standard DUT.accept(structure, path) visitor. I have
> highlighted the interesting part with bold. Do you see that instance G2
> thinks that it is G1? The secret of fast-and-scalable elaboration has has
> came to the surfice: Zamia builds no full (flattened) model in memory. For
> simulation, it is done later in simulator with drivers, as I understand. If
> you do not replicate every module instance in your design, it is not
> surprising that you do not spend memory. I suspected that it does not matter
> if you elaborate Leon or Goliath in this case but I could not believe that
> storing instance path inside the instance makes sense in this case.

your observation is correct! :) - But I was not aware it was a secret.
In fact, as far as I remember that was one of the main design points
in ZamiaCAD - not replicating the structure of re-instantiated
components.

The definition of structure.getPath() is therefore neither "return the
path of this instance" nor "enumerate all paths to this structure" but
simply "return one valid path to this structure" - this was used in
the eclipse plugin for people who address an design unit directly -
here we could use getPath() so we have at least some kind of valid
path in the navigation editline.

that said, all the information to build e.g. a complete simulation
model and also the ability to enumerate all existing paths in the
design from the top should still be preserved in IG so this kind of
information can be computed (and then maybe cached) on demand when it
is needed.

Don't remember too many details - my memory is a bit sketchy here
after all that time but anyway, I think it is extremely cool you keep
on diving into the zamia code while developing a deep understanding
how it works :)

Keep up the good work!

   guenter

[Zamiacad-devel] Secret of ZamiaCAD scalability

[Valentin T. <val...@gm...>]

There was a lot of hype around unique Zamia scalability but its proponents
could never expose the secret. Now, I decided to expand Zamia with EDIF
export and suddenly discovered that design

module DUT
  G1: module AND2
  G2: module AND2

has an interesting IG structure,

  path=DUT, structure.getPath()= WORK.TB:DUT
  path=DUT.G2, structure.getPath()= WORK.TB:DUT.G*1*
  path=DUT.G1, structure.getPath()= WORK.TB:DUT.G*1*

It is obtained using standard DUT.accept(structure, path) visitor. I have
highlighted the interesting part with bold. Do you see that instance G2
thinks that it is G1? The secret of fast-and-scalable elaboration has has
came to the surfice: Zamia builds no full (flattened) model in memory. For
simulation, it is done later in simulator with drivers, as I understand. If
you do not replicate every module instance in your design, it is not
surprising that you do not spend memory. I suspected that it does not
matter if you elaborate Leon or Goliath in this case but I could not
believe that storing instance path inside the instance makes sense in this
case.

best regards,
  valentin

[Zamiacad-devel] Patch for setting Debug Level

[Christian T. <zam...@ka...>]

Hello,
i wrote a quick patch, so the user will be able to set the Debug Level
as specified by org.apache.log4j.Level by setting a System Variable.
Uses Buildin function and sets Level.DEBUG if none is set.

greetings Christian

Re: [Zamiacad-devel] when should I use the interpreter?

[Guenter B. <gue...@gm...>]

valentin,

On Wed, May 22, 2013 at 12:00 AM, Valentin Tihomirov
<val...@gm...> wrote:
> I have discovered a bug (actually, it is rediculous, "for i in
> enum'low to enum'high" loops forever because enum'left=0 by LRM spec
> whereas the loop increment is based on i+enum'left). I am not sure if
> "+" must be supported for enums in general

either check LRM or consult the vhdl google group to be sure - I just
looked it up in ashenden's book and indeed, for the binary '+'
operator ashenden specifies "numeric" operands which enums probably
are not.

> but looking for options to
> fix, I stumbled at the question whether to interpret or not interpret
> again.
>
> I see that the loop generates the code
>
>                         IGType b = getContainer().findBoolType();
>                         IGObject param = getParameter();
>
> // here is the error, BTW, getOne() does getEnumLiteral(0)
>                         IGOperation one = param.getType().getOne(location);

without complete examples it is hard to judge what the problem is -
but just at first glance it is my feeling that getOne() simply does
the wrong thing for enums here when it returns 0

> and so on. I understand why exit condition must be checked at runtime.
> But, the object type seems known statically, at the code generation
> time.
> So, I cannot imagine how it is possible to support dynamic
> range, which seems the only reason for interpreter.

it is certainly stuff like open array subprogram parameters why this
code uses dynamic typing - but that doesn't mean it must be necessary.
so why not give it a try? implement the static case and drop it in
here and run the test suite - if it works, perfect. if not, see if the
static code can serve as an optimization in certain cases where the
boundaries are indeed static - I'd be optimistic that will be the case
quite often so as a worst case scenario we end up with "just" an
optimization :)

thanks,

   guenter

[Zamiacad-devel] when should I use the interpreter?

[Valentin T. <val...@gm...>]

I have discovered a bug (actually, it is rediculous, "for i in
enum'low to enum'high" loops forever because enum'left=0 by LRM spec
whereas the loop increment is based on i+enum'left). I am not sure if
"+" must be supported for enums in general but looking for options to
fix, I stumbled at the question whether to interpret or not interpret
again.

I see that the loop generates the code

			IGType b = getContainer().findBoolType();
			IGObject param = getParameter();

// here is the error, BTW, getOne() does getEnumLiteral(0)
			IGOperation one = param.getType().getOne(location);

			// init loop var

			aCode.add(new IGEnterNewContextStmt(location, getZDB()));
			aCode.add(new IGNewObjectStmt(param, location, getZDB()));
			
			aCode.add(new IGPushStmt(param, location, getZDB()));
			fRange.generateCode(true, aCode);
			aCode.add(new IGAttributeStmt(param.getType(), AttrOp.LEFT, false,
location, getZDB()));
			aCode.add(new IGPopStmt(false, false, false, location, getZDB()));

			// loop header: check boundaries

			IGLabel loop = new IGLabel();
			aCode.defineLabel(loop);
			IGLabel lhdesc = new IGLabel();
			fRange.generateCode(true, aCode);
			aCode.add(new IGAttributeStmt(param.getType(), AttrOp.ASCENDING,
false, location, getZDB()));
			aCode.add(new IGJumpNCStmt(lhdesc, location, getZDB()));

			aCode.add(new IGPushStmt(getParameter(), location, getZDB()));
			fRange.generateCode(true, aCode);
			aCode.add(new IGAttributeStmt(param.getType(), AttrOp.RIGHT, false,
location, getZDB()));
			aCode.add(new IGBinaryOpStmt(BinOp.LESSEQ, b, location, getZDB()));
			aCode.add(new IGJumpNCStmt(loopExitLabel, location, getZDB()));
			IGLabel loopbody = new IGLabel();
			aCode.add(new IGJumpStmt(loopbody, location, getZDB()));

			aCode.defineLabel(lhdesc);
			aCode.add(new IGPushStmt(getParameter(), location, getZDB()));
			fRange.generateCode(true, aCode);
			aCode.add(new IGAttributeStmt(param.getType(), AttrOp.RIGHT, false,
location, getZDB()));
			aCode.add(new IGBinaryOpStmt(BinOp.GREATEREQ, b, location, getZDB()));
			aCode.add(new IGJumpNCStmt(loopExitLabel, location, getZDB()));

			// loop body:



and so on. I understand why exit condition must be checked at runtime.
But, the object type seems known statically, at the code generation
time. So, I cannot imagine how it is possible to support dynamic
range, which seems the only reason for interpreter.

Thanks,
  valentin

[Zamiacad-devel] Fwd: zamiacad, it's time to upgrade your classic SourceForge project

[Guenter B. <gue...@gm...>]

---------- Forwarded message ----------
From: Rich Bowen <rb...@so...>
Date: Wed, Jan 23, 2013 at 8:22 PM
Subject: zamiacad, it's time to upgrade your classic SourceForge project
To: Guenter Bartsch <gu...@us...>


Dear zamiacad project admin,

Since your project has shown some activity in the last few months, we
want to be sure that you're aware that some changes are happening at
SourceForge, and we want to be sure you're not caught by surprise.

As you may already be aware, SourceForge is upgrading to a new platform
(code-named Allura), and as a result, we'll be retiring the Classic
SourceForge platform, which your project is still using. Our goal is to
have everybody off of the old platform in the first quarter of next
year, so that we can retire that code and focus our attention on the new
platform. It would, of course, be preferable if you migrate your own
project in your own time.

You can read more about the new platform at
https://sourceforge.net/p/upgrade/ and then, when you're ready, press
the Upgrade button next to your project name.

If you have any concerns about the process, or if your project has an
unusually large number of forums, source code repositories, or trackers,
please don't hesitate to contact us to discuss your upgrade. It's
important to us that it go smoothly.

As always, thanks for being part of the SourceForge community.

Rich Bowen
SourceForge Community Manager
rb...@so...

Re: [Zamiacad-devel] java programming: Replacing conditional code with polymorphism

[Guenter B. <gue...@gm...>]

valentin,

all of that sounds very impressive to me!

guess we need to clarify how bigger changes get approved and pushed
into the master branch - and also how we will make releases in the
future.

anton is the only one I know who might be actively working on the
codebase at the moment so maybe he can comment. if it is the case, you
two could simply review each other's changes if that seems beneficial
and decide on your own when to push those and when they should go into
releases.

if anton is busy I guess we should face the fact that you are the only
developer right now so it is completely up to you which changes you
would like to push.

personally I would love to get involved in zamia again, but cannot
promise anything. I have an FPGA related project starting soon and
maybe maybe there will be room to toy around with zamia at some point,
but details are still sketchy. I will definitely try to use IDE
webpack first and see what it can do.

best,

   guenter


On Fri, Nov 9, 2012 at 1:40 PM, Valentin Tihomirov <val...@gm...> wrote:
> Actually, I have once made a more large-scale refactoring when turned all
> core objects (IGItem, IGOperation and etc.) into interfaces. Not just
> because OOP books teach this "good practice" but trying to implement IGAlias
> easily, using java.reflection.proxy. I expected that I can make a universal
> alias object by just forwarding all calls directed to alias with calls to
> aliased object. However, it failed for IGObject search because signal search
> starts form the syntactic item, SignalDeclaration, while I achieve
> transparency at the IG level. Secondly, search stops at alias because alias
> has its own fID and DBID and search engine does not check if it is just an
> alias for another signal. So, full transaprence turned out not to be
> achievable. Though my java.proxy trick somewhat works for types and
> procedures. It has a flaw though also. The invocation shows that its
> procedure declaration is not alias but its referred proc. This is because
> alias forwards IGProcInvocation generation to the referred IGProcedure and
> invocation creates IGInvocation with a reference to itself rather than
> alias. Despite of this flaw, I can invoke the procedures by alias and
> elaborate VHDL 2008 textio that requires it. This branch is also waiting for
> approval.
>
>   valentin
>
>
> On Fri, Nov 9, 2012 at 1:27 PM, Guenter Bartsch <gue...@gm...>
> wrote:
>>
>> valentin,
>>
>> impressive work!
>>
>> can't really tell whether it is a good idea to push such a big change
>> into the master branch right away, maybe you want to consider keeping
>> it in a separate branch for maybe a few days so anton and others can
>> test it first?
>>
>> anyway, from my side no objections to pushing it to master right away.
>> anton?
>>
>> best,
>>
>>    guenter
>>
>>
>> On Fri, Nov 9, 2012 at 12:20 PM, Valentin Tihomirov
>> <val...@gm...> wrote:
>> >   Hi,
>> >
>> > Guenter, you are right that type casting in the interpreter becomes a
>> > pain. I therefore leave the generic interface for the static value
>> > (interface is set of methods and users need no type cast anything to
>> > work with them). Only fields are moved into subclasses. The subclasses
>> > override the appropriate methods. Dynamic type identification should
>> > not also be an issue because your original implementation relies
>> > exactly on this facility. IGType is still supplied to every static
>> > value during construction. Though your idea of ultimate mapping is
>> > still interesting.
>> >
>> > After converting StaticValue, IGOperationLiteral and IGPushStmt into
>> > OOP, I have conducted more experiments. Elaborating Leon has the same
>> > 0.5 sec penalty, despite its size is reduced 708MB -> 704 MB. This the
>> > same penalty I get in 30-sec simulator tests from the StableSuite.
>> > Yet, 108-sec robsy fault simulation time has clearly reduced to 100
>> > sec. Running multiple robsy simulation at a time does not seem to add
>> > additional benefit, as I expected. Yet, I'm still going to push this
>> > code into the master.
>> >
>> > Ok?
>> >
>> >    valentin
>> >
>> > On 10/28/12, Guenter Bartsch <gue...@gm...> wrote:
>> >> Valentin,
>> >>
>> >> On Sun, Oct 28, 2012 at 10:38 PM, Valentin Tihomirov
>> >> <val...@gm...> wrote:
>> >>> There are places in Zamia, e.g. in IGStaticValue and
>> >>> IGOperationLiteral, where code disregards the OOP polymorphism. It
>> >>> makes switch(cathegory) to decide what to do. The instances of such
>> >>> multivalued objects allocate mutually exclusive fields. For instance,
>> >>> when IGStaticValue represents an integer, only fNum matters while all
>> >>> other fileds, fAscending/Left/Right, fFile, fReal, fRecordFileds and
>> >>> etc are useless. They just consume memory and clutter namespace in
>> >>> debug. For a long time I hesitated to ask why such design choice was
>> >>> made and performed a test
>> >>>
>> >>> http://codereview.stackexchange.com/questions/18016/replacing-conditional-with-polymorphysm-slows-down-the-performance
>> >>
>> >> don't remember the exact ways these design decision were made - and,
>> >> as always, they could be wrong and improvements are always very
>> >> welcome :)
>> >>
>> >> so, as before, just a few remarks on what to watch out for:
>> >>
>> >> - make sure you run pass integrations tests after each refactoring
>> >>
>> >> - take special care with all code that processes the IG later. take
>> >> the interpreter for example: it may require some oo tricks to avoid
>> >> having many instanceof calls and casts in there if you map HDL types
>> >> to java classes. imagine an IGStaticValue residing on the
>> >> interpreter's stack which will now have to perform operations on it -
>> >> what is it supposed to do to perform the necessary type checks? what
>> >> about the bindings computation code which has to travers IG several
>> >> times to extract the information, how will it detect types?
>> >>
>> >> happy coding and keep up the good work,
>> >>
>> >>    guenter
>> >>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> _______________________________________________
> Zamiacad-devel mailing list
> Zam...@li...
> https://lists.sourceforge.net/lists/listinfo/zamiacad-devel
>

Re: [Zamiacad-devel] java programming: Replacing conditional code with polymorphism

[Valentin T. <val...@gm...>]

Actually, I have once made a more large-scale refactoring when turned all
core objects (IGItem, IGOperation and etc.) into interfaces. Not just
because OOP books teach this "good practice" but trying to implement
IGAlias easily, using java.reflection.proxy. I expected that I can make a
universal alias object by just forwarding all calls directed to alias with
calls to aliased object. However, it failed for IGObject search because
signal search starts form the syntactic item, SignalDeclaration, while I
achieve transparency at the IG level. Secondly, search stops at alias
because alias has its own fID and DBID and search engine does not check if
it is just an alias for another signal. So, full transaprence turned out
not to be achievable. Though my java.proxy trick somewhat works for types
and procedures. It has a flaw though also. The invocation shows that its
procedure declaration is not alias but its referred proc. This is because
alias forwards IGProcInvocation generation to the referred IGProcedure and
invocation creates IGInvocation with a reference to itself rather than
alias. Despite of this flaw, I can invoke the procedures by alias and
elaborate VHDL 2008 textio that requires it. This branch is also waiting
for approval.

  valentin

On Fri, Nov 9, 2012 at 1:27 PM, Guenter Bartsch
<gue...@gm...>wrote:

> valentin,
>
> impressive work!
>
> can't really tell whether it is a good idea to push such a big change
> into the master branch right away, maybe you want to consider keeping
> it in a separate branch for maybe a few days so anton and others can
> test it first?
>
> anyway, from my side no objections to pushing it to master right away.
> anton?
>
> best,
>
>    guenter
>
>
> On Fri, Nov 9, 2012 at 12:20 PM, Valentin Tihomirov
> <val...@gm...> wrote:
> >   Hi,
> >
> > Guenter, you are right that type casting in the interpreter becomes a
> > pain. I therefore leave the generic interface for the static value
> > (interface is set of methods and users need no type cast anything to
> > work with them). Only fields are moved into subclasses. The subclasses
> > override the appropriate methods. Dynamic type identification should
> > not also be an issue because your original implementation relies
> > exactly on this facility. IGType is still supplied to every static
> > value during construction. Though your idea of ultimate mapping is
> > still interesting.
> >
> > After converting StaticValue, IGOperationLiteral and IGPushStmt into
> > OOP, I have conducted more experiments. Elaborating Leon has the same
> > 0.5 sec penalty, despite its size is reduced 708MB -> 704 MB. This the
> > same penalty I get in 30-sec simulator tests from the StableSuite.
> > Yet, 108-sec robsy fault simulation time has clearly reduced to 100
> > sec. Running multiple robsy simulation at a time does not seem to add
> > additional benefit, as I expected. Yet, I'm still going to push this
> > code into the master.
> >
> > Ok?
> >
> >    valentin
> >
> > On 10/28/12, Guenter Bartsch <gue...@gm...> wrote:
> >> Valentin,
> >>
> >> On Sun, Oct 28, 2012 at 10:38 PM, Valentin Tihomirov
> >> <val...@gm...> wrote:
> >>> There are places in Zamia, e.g. in IGStaticValue and
> >>> IGOperationLiteral, where code disregards the OOP polymorphism. It
> >>> makes switch(cathegory) to decide what to do. The instances of such
> >>> multivalued objects allocate mutually exclusive fields. For instance,
> >>> when IGStaticValue represents an integer, only fNum matters while all
> >>> other fileds, fAscending/Left/Right, fFile, fReal, fRecordFileds and
> >>> etc are useless. They just consume memory and clutter namespace in
> >>> debug. For a long time I hesitated to ask why such design choice was
> >>> made and performed a test
> >>>
> http://codereview.stackexchange.com/questions/18016/replacing-conditional-with-polymorphysm-slows-down-the-performance
> >>
> >> don't remember the exact ways these design decision were made - and,
> >> as always, they could be wrong and improvements are always very
> >> welcome :)
> >>
> >> so, as before, just a few remarks on what to watch out for:
> >>
> >> - make sure you run pass integrations tests after each refactoring
> >>
> >> - take special care with all code that processes the IG later. take
> >> the interpreter for example: it may require some oo tricks to avoid
> >> having many instanceof calls and casts in there if you map HDL types
> >> to java classes. imagine an IGStaticValue residing on the
> >> interpreter's stack which will now have to perform operations on it -
> >> what is it supposed to do to perform the necessary type checks? what
> >> about the bindings computation code which has to travers IG several
> >> times to extract the information, how will it detect types?
> >>
> >> happy coding and keep up the good work,
> >>
> >>    guenter
> >>
>

Re: [Zamiacad-devel] java programming: Replacing conditional code with polymorphism

[Guenter B. <gue...@gm...>]

Valentin,

On Sun, Oct 28, 2012 at 10:38 PM, Valentin Tihomirov
<val...@gm...> wrote:
> There are places in Zamia, e.g. in IGStaticValue and
> IGOperationLiteral, where code disregards the OOP polymorphism. It
> makes switch(cathegory) to decide what to do. The instances of such
> multivalued objects allocate mutually exclusive fields. For instance,
> when IGStaticValue represents an integer, only fNum matters while all
> other fileds, fAscending/Left/Right, fFile, fReal, fRecordFileds and
> etc are useless. They just consume memory and clutter namespace in
> debug. For a long time I hesitated to ask why such design choice was
> made and performed a test
> http://codereview.stackexchange.com/questions/18016/replacing-conditional-with-polymorphysm-slows-down-the-performance

don't remember the exact ways these design decision were made - and,
as always, they could be wrong and improvements are always very
welcome :)

so, as before, just a few remarks on what to watch out for:

- make sure you run pass integrations tests after each refactoring

- take special care with all code that processes the IG later. take
the interpreter for example: it may require some oo tricks to avoid
having many instanceof calls and casts in there if you map HDL types
to java classes. imagine an IGStaticValue residing on the
interpreter's stack which will now have to perform operations on it -
what is it supposed to do to perform the necessary type checks? what
about the bindings computation code which has to travers IG several
times to extract the information, how will it detect types?

happy coding and keep up the good work,

   guenter

[Zamiacad-devel] java programming: Replacing conditional code with polymorphism

[Valentin T. <val...@gm...>]

There are places in Zamia, e.g. in IGStaticValue and
IGOperationLiteral, where code disregards the OOP polymorphism. It
makes switch(cathegory) to decide what to do. The instances of such
multivalued objects allocate mutually exclusive fields. For instance,
when IGStaticValue represents an integer, only fNum matters while all
other fileds, fAscending/Left/Right, fFile, fReal, fRecordFileds and
etc are useless. They just consume memory and clutter namespace in
debug. For a long time I hesitated to ask why such design choice was
made and performed a test
http://codereview.stackexchange.com/questions/18016/replacing-conditional-with-polymorphysm-slows-down-the-performance

best regards,
valentin

Re: [Zamiacad-devel] ast2ig transition

[Guenter B. <gue...@gm...>]

Valentin,

On Mon, Oct 22, 2012 at 4:21 PM, Valentin Tihomirov
<val...@gm...> wrote:
> I see that a search is made in a suitable IG module. It locates IG
> item closest to given line,col (the AST item location). Why this
> design choice was made instead of referencing resolved IG item from
> AST object? Was it an issue of graph partitioning for ZDB? Or, it is
> just good design?

maybe it was just bad design? ;-D

honestly, I don't really remember. I do recall we had a lot of trouble
taking the path information into account when it came to generate
statements - maybe the AST/AST -> IG approach is just not capable of
that or maybe it is just an implementation limitation.

this is the only thing i remember which one should watch out for when
trying to clean up this code

best,

   guenter

[Zamiacad-devel] ast2ig transition

[Valentin T. <val...@gm...>]

I see that a search is made in a suitable IG module. It locates IG
item closest to given line,col (the AST item location). Why this
design choice was made instead of referencing resolved IG item from
AST object? Was it an issue of graph partitioning for ZDB? Or, it is
just good design?

curious to know,
valentin

[Zamiacad-devel] Fwd: Memory optimization experiment

[Guenter B. <gue...@gm...>]

Valentin,

On Fri, Aug 31, 2012 at 1:02 PM, Valentin Tihomirov
<val...@gm...> wrote:

> I therefore analyzed what serialization does. The sizes of serialized
> objects fluctuate: sometimes my design gives smaller objects, especially
> serialized in the beginning, but it tends to produce larger objects in the
> end. Why? I have just removed a field!? The dump of a one of such serialized
> instances (of IGType) shows that java serializer produces a lot of garbage.

:) - don't think there is any real garbage in there. i suspect what
you see is the type information contained in every dump. the whole
process is well documented:

http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serialTOC.html

> Clean ZDB could be 100 times smaller.

definitely - and faster as well. there are plenty of alternatives to
java serialization

https://groups.google.com/forum/?fromgroups#!forum/java-serialization-benchmarking

which address the perceived issues in various ways - always depending
on what your specific requirements are (binary vs ascii, space vs
speed, platform-agnostic or specific, protocol compatibility,
security, easy of deployment, versioning, ...)

> Whether I debug with Guenter's or my ZDB, I always see that the IGType
> object, that is being serialized, has a field fRange, which has fAscending
> initialized to IGStaticValue with fId. But, Guenter's version does not save
> it! I do not understand what stops the static value from serialization.

http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250

"Default serializable fields of a class are defined to be the
non-transient and non-static fields."

> There is another magic in ZDB. I studied the persistence frameworks a little
> (object databases and clustering technologies). The transactions are
> normally considered as a feature of reliable storage. However, they are more
> important. You may not find it in the literature stated explicitly, but, it
> turns out that transactions play a key role in maintaining the object
> identity. Every cluster object used by application must present in
> transaction cache. Committing the transaction flushes the cache and
> invalidates all the references. It is an error to refer clustered objects
> outside the transaction. The frameworks, therefore, have a limitation on how
> many operations you may perform in the transactions (cache overflow). ZDB,
> on the other hand, says nothing about cache limitation. I see that cache can
> evict LRU object at any time. I do not understand how it is possible.

there is no magic here, it is just a design decision in ZDB: ZDB is
meant to be a cowboy-style, bare-to-the-metal object db which does not
have any proper transaction concept.

of course, one could implement a transaction scheme - or replace ZDB
by a different DB which does have transactions - and investigate what
the costs and benefits are. definitely hasn't been done.

historically, zamia didn't have any persistence for a very long time -
you always had to start from scratch (i.e. parse your VHDL code) and
build the model in memory. when we started working on industrial
designs, this of course wasn't feasible anymore so we started looking
into ways to persist the in-memory model.

at first we investigated using hibernate and store in various SQL
databases - all those attempts failed for two reasons:

- much too slow
- you lose a lot of agility (need to annotate the classes, need to
break up object references manually, ...)

then, I started implementing a very simple-minded, limited-scope,
optimized for raw speed custom persistence layer which then involved
into today's ZDB.

> I can easily imagine that some thread requests POJO from ZDB, and keeps a
> reference in some (local) field so that POJO remains in memory while evicted
> from ZDB cache so that the next time it is requested, ZDB instantiates a new
> POJO. ZDB is not aware of the copies referenced outside its cache. So you
> get two objects with the same identity in memory. How is this resolved?

not at all - ZDB is not designed to handle this for you. if you're
using ZDB, you have to know what you're doing.

best,

   guenter

[Zamiacad-devel] Memory optimization experiment

[Valentin T. <val...@gm...>]

Hi,

in continuation of the previous mail, where I guessed that memory is spent
inefficiently due to improper object model, I have conducted an experiment
of optimizing out a single field. The fId field is declared in
IGConteinerItem but not used in the IGOperation descendants (fId is tied to
null there). If IGConteinerItems need the field, then IGOperation is not a
container item, I decided. I therefore derived IGOperation from IGItem and
provided the getId/setId methods in the IGItem.This also seems stupid but
it does not consume memory. Only those classes which need fId, IGContainerItems
and IGStaticValue, will declare the fId and fill the getter and setter with
content. This touchstone shows a weird thing.

I expected that the result will work slightly faster. There should be lots
of IGOperation objects and when you eliminate unnecessary 4-byte (or 8
bytes for 64-bit systems) pointers in them, the machine should run the
tests slightly faster. Similar savings in space/time apply to the
serialization. So, it may be unnoticeable faster, but there is nothing to
slowdown. A thorough test however shows that my design adds 2 extra seconds
to the 171 sec-long test. And, ZDB size, the serialized objects, are not
smaller.

I therefore analyzed what serialization does. The sizes of serialized
objects fluctuate: sometimes my design gives smaller objects, especially
serialized in the beginning, but it tends to produce larger objects in the
end. Why? I have just removed a field!? The dump of a one of such
serialized instances (of IGType) shows that java serializer produces a lot
of garbage. Clean ZDB could be 100 times smaller. But, I digress. My
alternative IGTypes are 10 bytes larger because of extra fId in them! It
looks like I introduced a field instead of eliminating it!! What the hell?

Whether I debug with Guenter's or my ZDB, I always see that the IGType
object, that is being serialized, has a field fRange, which has fAscending
initialized to IGStaticValue with fId. But, Guenter's version does not save
it! I do not understand what stops the static value from serialization.

Because fAscending field is IGItem, it has DBID, it could be marked
'transient' and saved as integer DBID instead of serializing the whole
POJO. So, it is actually cool if it is not serialized. This is actually the
whole idea of partitioning the large user data models by ZDB. This is how
ZDB should work, the whole purpose of ZDB, as I understand it. The first
interesting thing, I want to ask, why fAscending is not marked as
'transient'? Secondly, why it is not serialized despite of this (and what
do I break when move the fId field directly into IGStaticValue)? In the
whole zamiacad, there are only two writeObject overridings, in IGType and
IGOperation, and, they do not more than just forcing some their subobjects
into zdb (this gives a subobject zdb ID) and proceed with default
serialization. The default serialization should serialize fAscending as
well. So, I do not understand what kind of magic Guenter uses to prevent
serialization and why it does not work in my case.

There is another magic in ZDB. I studied the persistence frameworks a
little (object databases and clustering technologies). The transactions are
normally considered as a feature of reliable storage. However, they are
more important. You may not find it in the literature stated explicitly,
but, it turns out that transactions play a key role in maintaining the
object identity. Every cluster object used by application must present in
transaction cache. Committing the transaction flushes the cache and
invalidates all the references. It is an error to refer clustered objects
outside the transaction. The frameworks, therefore, have a limitation on
how many operations you may perform in the transactions (cache overflow).
ZDB, on the other hand, says nothing about cache limitation. I see that
cache can evict LRU object at any time. I do not understand how it is
possible.

I can easily imagine that some thread requests POJO from ZDB, and keeps a
reference in some (local) field so that POJO remains in memory while
evicted from ZDB cache so that the next time it is requested, ZDB
instantiates a new POJO. ZDB is not aware of the copies referenced outside
its cache. So you get two objects with the same identity in memory. How is
this resolved? Is it programmer's responsibility to beware what can be
evicted and which implication it may have or the magic, like the one seen
in the first part of this letter, does this job automatically? I cannot
figure out the proper ZDB workflow myself. ZDB is so fundamental but more I
learn it, the more I realize that I do not understand it and cannot build
upon it.

thanks,
val

[Zamiacad-devel] Why static value builder?

[Valentin T. <val...@gm...>]

Hello, I have implemented the textio.write method and realized the
lack of pointers (access type) support. I considered what can be done
in this direction and therefore revised the static value (builder).

Both static values and their builder attempt to be everything. They
include fields to support every type. They almost entirely consist of
unused fields. For instance, BigInteger fNum, BigDecimal fReal,
ArrayList<IGStaticValue> fArrayValues, int fArrayOffset,
HashMapArray<String, IGStaticValue> fRecordValues, File fFile,
IGStaticValue fLeft, fRight, fAscending,boolean fIsBuiltinBool and
fTruthValue are all unnecessary for a character value. I am also sure
that bool fIsCharLiteral and char fCharLiteral are also unnecessary
when we have fEnumOrd and reference to the type. Though this is
acceptable for the builder, there seems to be lot of StaticValue
instances during simulation, which should consume a lot of memory (not
to speak about implications of the clutter for the programmer). The
same issue applies to SignalDrivers.

All the unnecessary fields consume memory, which contradicts to the
principle you explained me in the last year that scalability dictates
us to share and compute over copying. Too large memory demand also
elides such important feature as mem cache and thus further degrades
the computer bottleneck, the CPU-memory connection. The
memory-friendly model is thus a prerequisite for faster and parallel
simulation.

Secondly, I wanted to ask, what is the value of the value builder?
Immutability of static values? But ok, if model is immutable then how
do we alter the object behind the pointer so that other pointers see
the updated object,

l1 := new string'("abc")
l2 := l1
read(l1, char); // read one char, l1: abc -> bc
assert l2'length = 2;

In zamia, l2 = "abc" whereas it must be "bc". Do you have an idea?

regards,
valentin

[Zamiacad-devel] ZDB cache

[Valentin T. <val...@gm...>]

I wonder, why did you choose to implement your own cache? You do it
using HashMap + LinkedList but LinkedHashMap does both for free!
Secondly, instead of keeping the linked list in sync with map, when
deleting a node, you remove it only from the map, mark "deleted" but
leave in the list

	public synchronized void delete(long aId) {

		ZDBCacheEntry entry = fCache.get(aId);
		if (entry != null) {
			entry.setDirty(false);
			entry.setDeleted(true);
			fCache.remove(aId);
		}

and check this flag in eviction

	private synchronized void evict() {
		long id = fCacheTail.getId();
		ZDBCacheEntry evictedEntry = fCache.remove(id);
		if (evictedEntry == null) {
			if (!fCacheTail.isDeleted()) {
				System.out.printf("ZDB: Internal error: id %d was not part of
cache.\n", id);
			}

Do you introduce a feature just to debug it? :)

I have also noticed automated to the reckless use of design pattern :)

new BufferedOutputStream(new LevelGZIPOutputStream(file)));

Let alone the efficiency of buffering uncompressed vs. compressed.
Don't you think that zip processor writing right into the file makes
the buffering a little bit useless :)) I see a lot of single bit
writes in the file system monitor because of that. I have also
replaced the open/close data.bin every access policy with
"keep-it-open-while-zdb-is-not-shutdown". All together, ZDBtest shows
speedup from 75 to 5 seconds! I was told that this is the difference
we have between Windows and Linux. This confirms that Windows policy
is to flush by default, while Linux speculatively buffers the file
operations.

best regards,
valentin

Re: [Zamiacad-devel] VHDL-to-SystemC converter ver2

[valentin T. <val...@gm...>]

Hi,

To help you making first steps in zamia and git, we have created
systemc branch it git and IG2SC.java in the instgrapgh package. Please
find it at SourceForge. In Windows, we use msysgit and are always
ready to help through Google Talk or skype with a fast response. But,
surely you'll need to learn something about git yourself. You commit
locally and guenter grants sourceforge repository write access.

Perhaps, somebody else recommends a good location for your test suite classes.

Best regards,
valentin



On 1/29/12, Saif Abrar <sye...@gm...> wrote:
> Friends,
> here is the updated ver2 VHDL-to-SystemC converter, supporting more
> VHDL constructs and robust than earlier.
>
> Steps for using the VHDL-to-SysC converter:
> - Merge the attached IG2DOT.java file with the file in your workspace,
> in dir zamiacad/src/org/zamia/instgraph
> - Now the SysC RTL can also be generated ! in addition to the already
> existing IG2DOT dump.
> - The IG2DOT functionality is tested by the file
> zamiacad/test/org/zamia/instgraph/IGDumpTest.java
> - This file instantiates AST2DOT and IG2DOT, as:
>             AST2DOT dot = new AST2DOT(arch);
>             IG2DOT dot = new IG2DOT(module);
> - For the IG2DOT instance, there is a try-block that invokes the
> IG2DOT convert method:
>            dot.convert(out);
>  After this line, invoke the VHDL-to-SysC convert method:
>           dot.sc_convert(aTestDir);
> - So now the try-block will look like
> 	try {
> 		out = new PrintWriter(new BufferedWriter(new FileWriter(aIGDotFile)));
> 		dot.convert(out);
> 		dot.sc_convert(aTestDir); //VHDL to SystemC
> 		logger.info("IGDumpTest: wrote dot file to %s", aIGDotFile);
> 	} catch (IOException e)
>
> - Running the simulation will invoke the VHDL-to-SysC converter.
> - For SysC, 2 files are generated in the same directory where the
> BuildPath.txt is present:
>                   sc_model.h
>                   sc_model.cpp
>
>
> Feel free to let me know your feedback.
>
> --
> Best regards,
> Saif Abrar
> Bangalore(India)
>

[Zamiacad-devel] VHDL-to-SystemC converter ver2

[Saif A. <sye...@gm...>]

Friends,
here is the updated ver2 VHDL-to-SystemC converter, supporting more
VHDL constructs and robust than earlier.

Steps for using the VHDL-to-SysC converter:
- Merge the attached IG2DOT.java file with the file in your workspace,
in dir zamiacad/src/org/zamia/instgraph
- Now the SysC RTL can also be generated ! in addition to the already
existing IG2DOT dump.
- The IG2DOT functionality is tested by the file
zamiacad/test/org/zamia/instgraph/IGDumpTest.java
- This file instantiates AST2DOT and IG2DOT, as:
            AST2DOT dot = new AST2DOT(arch);
            IG2DOT dot = new IG2DOT(module);
- For the IG2DOT instance, there is a try-block that invokes the
IG2DOT convert method:
           dot.convert(out);
 After this line, invoke the VHDL-to-SysC convert method:
          dot.sc_convert(aTestDir);
- So now the try-block will look like
	try {
		out = new PrintWriter(new BufferedWriter(new FileWriter(aIGDotFile)));
		dot.convert(out);
		dot.sc_convert(aTestDir); //VHDL to SystemC
		logger.info("IGDumpTest: wrote dot file to %s", aIGDotFile);
	} catch (IOException e)

- Running the simulation will invoke the VHDL-to-SysC converter.
- For SysC, 2 files are generated in the same directory where the
BuildPath.txt is present:
                  sc_model.h
                  sc_model.cpp


Feel free to let me know your feedback.

-- 
Best regards,
Saif Abrar
Bangalore(India)

Re: [Zamiacad-devel] issues in 'mux' IG

[Anton C. <ant...@gm...>]

Saif,

You seem to be using the old code. This bug was fixed some time ago:

Author: Anton Chepurov <ant...@gm...>  2011-10-10 17:49:12
Committer: Anton Chepurov <ant...@gm...>  2011-10-10 17:49:12
Parent: 5a97606990e76aad6904b2a91efb3a7b6c34ed95 (fix gcounter VCD test)
Child:  6fa15baeec410374d7df8e6863c623994691dcba (fix second's size in
standard.vhdl)
Branches: hldd, master, remotes/origin/hldd, remotes/origin/master
Follows: 0.10.1
Precedes: 0.10.2

    fix VHDL2008 parser (if-elsif-ELSE)


Best,
Anton

On Tue, Jan 17, 2012 at 1:56 PM, Guenter Bartsch
<gue...@go...> wrote:
> Saif,
>
> On Mon, Jan 16, 2012 at 7:24 PM, Saif Abrar <sye...@gm...> wrote:
>> hello Guenter,
>> as part of the VHDL-to-SC conversion, I was looking at the GCD-2 code.
>> there is a description of a mux as follows:
>>
>> entity mux is
>>    port(       rst, sLine: in std_logic;
>>                load, result: in std_logic_vector( 3 downto 0 );
>>                output: out std_logic_vector( 3 downto 0 )
>>    );
>> end mux;
>> architecture mux_arc of mux is
>> begin
>>    process( rst, sLine, load, result )
>>    begin
>>        if( rst = '1' ) then
>>            output <= "0000";           -- do nothing
>>        elsif sLine = '0' then
>>            output <= load;             -- load inputs
>>        else
>>            output <= result;           -- load results
>>        end if;
>>    end process;
>> end mux_arc;
>>
>> there are few doubts that need clarifications:
>> 1. in this mux description, the last assignment operation (output <=
>> result;) is
>> the 'else' clause of the second if-statement (if sLine = '0').
>> Correct?
>
> yes
>
>> 2. in the IG graph, the second if-statement (if sLine = '0') and the
>> last assignment operation (output <= result;)
>> both are coming within the first 'else' statement.
>> logically, this renders the code as:
>>        IF ( rst = '1' ) then
>>            output <= "0000";
>>        ELSE
>>            IF sLine = '0' then output <= load;
>>                ELSE nothing;
>>                END-IF
>>            output <= result; //this line will always be executed within this 'else'
>>        END-IF
>>
>> I am copying below the DOT code starting from the first if-statement
>> (rst = '1').
>> Please clarify if I am mis-interpreting something in this context.
>
> if this is really the IG that is being generated we definitely have a bug here.
>
> i dimly remember we had once fixed a bug in the elsif-conversion
> algorithm, i wonder whether that bugfix was lost or if this is a
> separate issue.
>
> saif, can you (or anyone else) confirm the IG is broken in this case
> e.g. by running the test case in zamia's simulator? (sorry, don't have
> time to do that myself right now)
>
> best,
>
>   guenter
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Zamiacad-devel mailing list
> Zam...@li...
> https://lists.sourceforge.net/lists/listinfo/zamiacad-devel

Re: [Zamiacad-devel] issues in 'mux' IG

[Guenter B. <gue...@go...>]

Saif,

On Mon, Jan 16, 2012 at 7:24 PM, Saif Abrar <sye...@gm...> wrote:
> hello Guenter,
> as part of the VHDL-to-SC conversion, I was looking at the GCD-2 code.
> there is a description of a mux as follows:
>
> entity mux is
>    port(       rst, sLine: in std_logic;
>                load, result: in std_logic_vector( 3 downto 0 );
>                output: out std_logic_vector( 3 downto 0 )
>    );
> end mux;
> architecture mux_arc of mux is
> begin
>    process( rst, sLine, load, result )
>    begin
>        if( rst = '1' ) then
>            output <= "0000";           -- do nothing
>        elsif sLine = '0' then
>            output <= load;             -- load inputs
>        else
>            output <= result;           -- load results
>        end if;
>    end process;
> end mux_arc;
>
> there are few doubts that need clarifications:
> 1. in this mux description, the last assignment operation (output <=
> result;) is
> the 'else' clause of the second if-statement (if sLine = '0').
> Correct?

yes

> 2. in the IG graph, the second if-statement (if sLine = '0') and the
> last assignment operation (output <= result;)
> both are coming within the first 'else' statement.
> logically, this renders the code as:
>        IF ( rst = '1' ) then
>            output <= "0000";
>        ELSE
>            IF sLine = '0' then output <= load;
>                ELSE nothing;
>                END-IF
>            output <= result; //this line will always be executed within this 'else'
>        END-IF
>
> I am copying below the DOT code starting from the first if-statement
> (rst = '1').
> Please clarify if I am mis-interpreting something in this context.

if this is really the IG that is being generated we definitely have a bug here.

i dimly remember we had once fixed a bug in the elsif-conversion
algorithm, i wonder whether that bugfix was lost or if this is a
separate issue.

saif, can you (or anyone else) confirm the IG is broken in this case
e.g. by running the test case in zamia's simulator? (sorry, don't have
time to do that myself right now)

best,

   guenter

[Zamiacad-devel] issues in 'mux' IG

[Saif A. <sye...@gm...>]

hello Guenter,
as part of the VHDL-to-SC conversion, I was looking at the GCD-2 code.
there is a description of a mux as follows:

entity mux is
    port(	rst, sLine: in std_logic;
		load, result: in std_logic_vector( 3 downto 0 );
		output: out std_logic_vector( 3 downto 0 )
    );
end mux;
architecture mux_arc of mux is
begin
    process( rst, sLine, load, result )
    begin
	if( rst = '1' ) then
	    output <= "0000";		-- do nothing
	elsif sLine = '0' then
	    output <= load;		-- load inputs
	else
	    output <= result;		-- load results
	end if;
    end process;
end mux_arc;

there are few doubts that need clarifications:
1. in this mux description, the last assignment operation (output <=
result;) is
the 'else' clause of the second if-statement (if sLine = '0').
Correct?

2. in the IG graph, the second if-statement (if sLine = '0') and the
last assignment operation (output <= result;)
both are coming within the first 'else' statement.
logically, this renders the code as:
	IF ( rst = '1' ) then
	    output <= "0000";
	ELSE
	    IF sLine = '0' then output <= load;
	        ELSE nothing;
	        END-IF
	    output <= result; //this line will always be executed within this 'else'
	END-IF

I am copying below the DOT code starting from the first if-statement
(rst = '1').
Please clarify if I am mis-interpreting something in this context.

thanks,
Saif


o4763369[shape=none,margin=0,label=<
<TABLE BORDER="0" CELLBORDER="1" CELLSPACING="0" CELLPADDING="4">
<TR><TD COLSPAN="2">org.zamia.instgraph.IGSequentialIf</TD></TR>
 <TR><TD>fThenSOS</TD><TD PORT="p0">obj</TD></TR>
 <TR><TD>fElseSOS</TD><TD PORT="p1">obj</TD></TR>      <==============
the Else-SOS resolves to 2 statements
 <TR><TD>fCond</TD><TD PORT="p2">obj</TD></TR>
 <TR><TD>fId</TD><TD PORT="p3">null</TD></TR>
  </TABLE>>];
  o4763369:p0 -> o22716491;
  o4763369:p1 -> o13745259;
  o4763369:p2 -> o29275392;


o13745259[shape=none,margin=0,label=<
<TABLE BORDER="0" CELLBORDER="1" CELLSPACING="0" CELLPADDING="4">
<TR><TD COLSPAN="2">org.zamia.instgraph.IGSequenceOfStatements</TD></TR>
 <TR><TD>fStmts</TD><TD PORT="p0">obj</TD></TR>
 <TR><TD>fId</TD><TD PORT="p1">null</TD></TR>
  </TABLE>>];
  o13745259:p0 -> o391089378;

  o391089378[shape=none,margin=0,label=<
<TABLE BORDER="0" CELLBORDER="1" CELLSPACING="0" CELLPADDING="4">
<TR><TD COLSPAN="2">java.util.ArrayList</TD></TR>
 <TR><TD>size</TD><TD PORT="p0">2</TD></TR>
  </TABLE>>];
  o391089378:p0 -> o12115416;
  o391089378:p0 -> o15510521;

    o12115416[shape=none,margin=0,label=<
<TABLE BORDER="0" CELLBORDER="1" CELLSPACING="0" CELLPADDING="4">
<TR><TD COLSPAN="2">org.zamia.instgraph.IGSequentialIf</TD></TR>
 <TR><TD>fThenSOS</TD><TD PORT="p0">obj</TD></TR>
 <TR><TD>fElseSOS</TD><TD PORT="p1">null</TD></TR>
<================= there is no statement in the 'else'
 <TR><TD>fCond</TD><TD PORT="p2">obj</TD></TR>
 <TR><TD>fId</TD><TD PORT="p3">null</TD></TR>
  </TABLE>>];
  o12115416:p0 -> o27869524;
  o12115416:p2 -> o25931923;


o15510521[shape=none,margin=0,label=<
<TABLE BORDER="0" CELLBORDER="1" CELLSPACING="0" CELLPADDING="4">
<TR><TD COLSPAN="2">org.zamia.instgraph.IGSequentialAssignment</TD></TR>
 <TR><TD>fValue</TD><TD PORT="p0">obj</TD></TR>
 <TR><TD>fTarget</TD><TD PORT="p1">obj</TD></TR>
 <TR><TD>fId</TD><TD PORT="p2">null</TD></TR>
  </TABLE>>];
  o15510521:p0 -> o948824;
  o15510521:p1 -> o8542380;

Re: [Zamiacad-devel] VHDL-to-SystemC_RTL implementation

[Guenter B. <gue...@go...>]

saif,

On Mon, Jan 2, 2012 at 11:24 AM, Saif Abrar <sye...@gm...> wrote:
> Friends,
> Please find attached the first implementation of VHDL-to-SystemC converter,
> using zamiacad.

impressive!

> Guenter, I am not able to get the entity and the architecture name from the
> IG-graphs, using the DOT-conversion approach.
> Please let me know how to get these info from within IG-graph.

getDUUID() should give you that information - of course in a bit of an
abstracted way (there is no concept of entity-architecture on the IG
level as this is VHDL-specific and IG is supposed to be
language-agnostic)

getDUUID (which should be refactored to getDMUID...) will result in a
DMUID object:


public class DMUID implements Serializable {

        public final static String SEPARATOR = "_#_";

        public enum LUType {
                Entity, Architecture, Package, PackageBody, Configuration
        };

        private final LUType fType;

        private final String fLibId, fId, fArchId, fUID;


provided that the IGModule you called this on originated from VHDL,
fID will contain the entity id while fArchId will contain the
architecture id.

best,

   guenter