Modelsim PE vs. Aldec Active-HDL (PE)

On Mar 5, 4:53=A0pm, Andy Peters <goo...@latke.net> wrote:
>
> It turns out that it is reasonable to create one workspace for an FPGA
> project and within this workspace create a "design" for the
> subentities and the top level. If you let it use the design name as
> the working library for the design, then as long as you "use" the
> library in a higher-level source, that source can see those other
> libraries.

Why do you think that you need to segregate the library that the
source files get compiled into?  In other words, what is wrong with
compiling everything into 'work'?  That's not a source file, it's an
intermediate folder(s) that gets created along the way to doing what
you need to have done.  What do you gain by trying to have tidy
intermediate folders?

Having a separate library helps you avoid name clashes, but for things
that you're developing yourself this is more easily avoided by
considering some of the following points:
- Question the validity of why you have two things named the same
(presumably doing the same thing)
- Consider parameterizing the design instead so that there is only one
thing with that name, but now you have a parameter that can select
what needs to be different.
- If the differences between the designs are significant such that
parameterizing simply encapsulates each approach within big 'if xyz
generate...end generate', if abc generate...end generate' statements
then consider collecting each design as simply differently named
architectures of the same entity (i.e. 'architecture RTL1 of widget',
'architecture RTL2 of widget')
- Avoid the name clash by renaming one of them to be more descriptive
to distinguish it from it's sibling

>
> Now I'm thinking that the usual method of doing:
>
> =A0 =A0 u_foo : entity work.foo port map (bar =3D> bar, bletch =3D> bletc=
h);
>
> might be better as:
>
> =A0 =A0 u_foo : entity foo.foo port map (bar =3D> bar, bletch =3D> bletch=
);
>
> The other option is to create a package with a component definition
> for foo, and analyze that package into the foo library, so the
> instantiation can be:
>
> =A0 =A0 u_foo : foo port map (bar =3D> bar, bletch =3D> bletch);
>
> I really don't know which is "better."
>

Neither one is particularly good in my opinion.  The reasons against
the first approach I've mentioned above (i.e. what do you really get
for not simply compiling everything into 'work'?).  The only place
I've found a component declaration to be useful is when you would like
to use a configuration to swap things out and about.  The only time
I've found configurations to be useful really is when the VHDL source
is not really under my control (such as when a PCBA model is generated
by a CAD tool).

With a component declaration, you still have to decide where to put
that declaration.  The best place is in the source file with the
entity so that changes to one are more likely to get changed in both
places.  Given that, I don't see how components will help you manage
anything better....my two or three cents

Kevin Jennings

On Sat, 6 Mar 2010 08:41:57 -0800 (PST), KJ <kkjennings@sbcglobal.net> wrote:

>On Mar 5, 4:53&#4294967295;pm, Andy Peters <goo...@latke.net> wrote:
>>
>> It turns out that it is reasonable to create one workspace for an FPGA
>> project and within this workspace create a "design" for the
>> subentities and the top level. If you let it use the design name as
>> the working library for the design, then as long as you "use" the
>> library in a higher-level source, that source can see those other
>> libraries.
>
>Why do you think that you need to segregate the library that the
>source files get compiled into?  In other words, what is wrong with
>compiling everything into 'work'?  That's not a source file, it's an
>intermediate folder(s) that gets created along the way to doing what
>you need to have done.  What do you gain by trying to have tidy
>intermediate folders?

as you said, tidiness...

I use separate libraries for major categories within the design; e.g. memory
interface, core logic, common (reusable) blocks, testbench - not separate
libraries for foo, bar and bletch. 

I can't say it buys me a whole lot but it does help me keep the design hierarchy
straighter - e.g. if the synthesis project contains something from the Testbench
library, the design has gone seriously astray somewhere!

though Xilinx EDK also uses it to version libraries that are common (apart from
being different versions) to different IP blocks.

>Having a separate library helps you avoid name clashes,

not if you're using Xilinx XST it doesn't... unfortunately. 

Incredibly, XST doesn't support VHDL qualified identifiers from different
libraries. In the presence of unqualified name clashes it will pick the right
name from whichever library it wants, so WILL synthesise something completely
different from what you intended, and tested in simulation.

This has been around since 6.1 at least, and may or may not be fixed in ISE 12.

which, as far as I can see, is the ONLY reason why all those EDK blocks get
separately synthesised, then black boxed into the top level design.

- Brian

> > What do you gain by trying to have tidy intermediate folders?
>
> as you said, tidiness...
>

tidy intermediate folders...i.e. folders that are not important to me
as the user of the tool, but are needed by the tool to do it's job.
In other words, I don't care if the tool's private folders are tidy or
not.

> I use separate libraries for major categories within the design; e.g. memory
> interface, core logic, common (reusable) blocks, testbench - not separate
> libraries for foo, bar and bletch.
>

My point was why even bother to separate them unless there are name
clashes...or perhaps you're creating your own separate IP for resale
and want to avoid clashes with some other potential IP.

> I can't say it buys me a whole lot

I agree

> but it does help me keep the design hierarchy
> straighter - e.g. if the synthesis project contains something from the Testbench
> library, the design has gone seriously astray somewhere!
>

If it's actually a problem, the synthesis tool will complain quickly
(like less than 1 minute into the run)...but the synthesis tool won't
be looking at any libraries (testbench or other) it will create the
libraries itself based on the source files you tell it are in there to
be synthesized.  Whether you compile such a testbench file into 'work'
or 'testbench' won't matter.  If the source file is included it will
be analyzed.  If it happens to be synthesizable code (even if it is
only intended for sim testbench) synthesis will be OK with it.  It
won't generate any logic from this extraneous code since it won't be
called from within the hierarchy of the design to be synthesized.

I confess though, I'm not quite sure what your point is here for
compiling stuff into separate libraries.  It *sounds* like you're
talking about organizing source files into separate 'libraries'...in
which case what you said would make more sense but that's not at all
the same thing as compiling something into a library other than
'work'.

Kevin Jennings

rickman <gnuarm@gmail.com> writes:

> I find the GUI will save me a lot of typing when instantiating
> modules.  I use the "generate test bench" feature to build a file
> with the meat and potatoes in it and I copy that to the higher level
> module.

Ahh, I use VHDL-mode in Emacs for that, which is why I haven't missed
it :)


-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

KJ <kkjennings@sbcglobal.net> writes:

> On Mar 5, 5:34&#4294967295;am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>>
>> Am I the only one that makes *no* use of the various "project things"
>> (either in Modelsim or Aldec)? &#4294967295;I just have a makefile and use the GUI
>> to run the sim (from "their" command-line) and show me the waveforms.
>> I guess I don't like to be tied to a tool (as much as I can manage)
>> much as I don't like to be tied to a particular silicon vendor (as
>> much as I can manage :)
>>
>
> But you're also running *their* commands to compile, run and view so
> you're not really any more independent.  

This is true, but the "porting" can be done once and pushed into
scripts.  Porting my "muscle-memory" is a lot harder, if the buttons
to click move around :)

Waveform viewing is still an issue, as that will likely change the
most, but I spend a lot less time doing that than most other tasks.
Certainly, the differences between two tools didn't pain me much when
I was trying two in parallel.

> Maintaining make files can be a chore also, unless you use something
> to help you manage it...but then you're now dependent on that tool
> as well.

Emacs.  I don't mind being dependent on that so much.

>
>> Am I missing something valuable, or is it just different?
>>
> Probably depends on which scenario is more likely to occur
> 1. Change sim tools

Or using a variety all the time... I'd like to do more experimentation
and comparison, esp. of the open source tools.

> 2. Add new developers (temporary, or because you move on to something
> else in the company)
>
> If #1 is prevalent, then maybe using other tools to help you manage
> 'make' is better.  If #2 is more prevalent, then using the tool's
> project system is probably better in easing the transition.  

I guess that's a point in its favour (assuming I can't "convert" the
incomers to Emacs :)

> If neither is particularly likely...well...then it probably doesn't
> much matter since one can probably be just as productive with
> various approaches.

Which is probably why we have lots of approaches - dofferent strokes
and all that!

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

On Mar 6, 9:41=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
> On Mar 5, 4:53=A0pm, Andy Peters <goo...@latke.net> wrote:
>
>
>
> > It turns out that it is reasonable to create one workspace for an FPGA
> > project and within this workspace create a "design" for the
> > subentities and the top level. If you let it use the design name as
> > the working library for the design, then as long as you "use" the
> > library in a higher-level source, that source can see those other
> > libraries.
>
> Why do you think that you need to segregate the library that the
> source files get compiled into? =A0In other words, what is wrong with
> compiling everything into 'work'? =A0That's not a source file, it's an
> intermediate folder(s) that gets created along the way to doing what
> you need to have done. =A0What do you gain by trying to have tidy
> intermediate folders?

As I said, I have always just dumped everything into 'work' without
thinking too much about it, mainly because it always just worked. I
thought about using separate libraries as a sop to how Active-HDL
organizes its workspaces.

> Having a separate library helps you avoid name clashes, but for things
> that you're developing yourself this is more easily avoided by
> considering some of the following points:
> - Question the validity of why you have two things named the same
> (presumably doing the same thing)

No issues with namespaces here. I've adopted a simple prefix
nomenclature for things that hopefully mitigates any potential
clashes.

> > Now I'm thinking that the usual method of doing:
>
> > =A0 =A0 u_foo : entity work.foo port map (bar =3D> bar, bletch =3D> ble=
tch);
>
> > might be better as:
>
> > =A0 =A0 u_foo : entity foo.foo port map (bar =3D> bar, bletch =3D> blet=
ch);
>
> > The other option is to create a package with a component definition
> > for foo, and analyze that package into the foo library, so the
> > instantiation can be:
>
> > =A0 =A0 u_foo : foo port map (bar =3D> bar, bletch =3D> bletch);
>
> > I really don't know which is "better."
>
> Neither one is particularly good in my opinion. =A0The reasons against
> the first approach I've mentioned above (i.e. what do you really get
> for not simply compiling everything into 'work'?). =A0The only place
> I've found a component declaration to be useful is when you would like
> to use a configuration to swap things out and about. =A0The only time
> I've found configurations to be useful really is when the VHDL source
> is not really under my control (such as when a PCBA model is generated
> by a CAD tool).

I agree: I never use component declarations except to work around
other tool issues (like with the Xilinx EDK and how it apparently
analyzes things into particular non-work libraries).

> With a component declaration, you still have to decide where to put
> that declaration. =A0The best place is in the source file with the
> entity so that changes to one are more likely to get changed in both
> places. =A0Given that, I don't see how components will help you manage
> anything better....my two or three cents

Those component declarations I've described are in a package that's in
the same source file as the entity.

I think I need to simply stop using the Active-HDL GUI and do the
command-line thing.

-a

On Mar 8, 6:53=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> rickman <gnu...@gmail.com> writes:
> > I find the GUI will save me a lot of typing when instantiating
> > modules. =A0I use the "generate test bench" feature to build a file
> > with the meat and potatoes in it and I copy that to the higher level
> > module.
>
> Ahh, I use VHDL-mode in Emacs for that, which is why I haven't missed
> it :)

Are you saying that Emacs understands VHDL well enough to build a test
bench for you?  Will it also build a component declaration or
instantiation automatically?  These three things could be automated,
but I have never taken the time to do it.  Making it part of the
editor makes perfect sense.

Rick

On Mar 8, 7:04=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> KJ <kkjenni...@sbcglobal.net> writes:
>
> I guess that's a point in its favour (assuming I can't "convert" the
> incomers to Emacs :)

You can convert me.  I just need to know that it is an advantage to
switch.

Rick

On Mar 8, 1:32=A0pm, rickman <gnu...@gmail.com> wrote:
> On Mar 8, 6:53=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>
> > rickman <gnu...@gmail.com> writes:
> > > I find the GUI will save me a lot of typing when instantiating
> > > modules. =A0I use the "generate test bench" feature to build a file
> > > with the meat and potatoes in it and I copy that to the higher level
> > > module.
>
> > Ahh, I use VHDL-mode in Emacs for that, which is why I haven't missed
> > it :)
>
> Are you saying that Emacs understands VHDL well enough to build a test
> bench for you?

It will create a skeleton for you.

>=A0Will it also build a component declaration or
> instantiation automatically? =A0These three things could be automated,
> but I have never taken the time to do it. =A0Making it part of the
> editor makes perfect sense.

The skeleton has a nice header, an instance of the DUT, signal
declarations for all DUT I/O and a simple clock generator. Of course
you have to create your own stimulus and add instantiations of other
models as necessary.

-a

On Mar 8, 4:40=A0pm, Andy Peters <goo...@latke.net> wrote:
> On Mar 8, 1:32=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > On Mar 8, 6:53=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>
> > > rickman <gnu...@gmail.com> writes:
> > > > I find the GUI will save me a lot of typing when instantiating
> > > > modules. =A0I use the "generate test bench" feature to build a file
> > > > with the meat and potatoes in it and I copy that to the higher leve=
l
> > > > module.
>
> > > Ahh, I use VHDL-mode in Emacs for that, which is why I haven't missed
> > > it :)
>
> > Are you saying that Emacs understands VHDL well enough to build a test
> > bench for you?
>
> It will create a skeleton for you.
>
> >=A0Will it also build a component declaration or
> > instantiation automatically? =A0These three things could be automated,
> > but I have never taken the time to do it. =A0Making it part of the
> > editor makes perfect sense.
>
> The skeleton has a nice header, an instance of the DUT, signal
> declarations for all DUT I/O and a simple clock generator. Of course
> you have to create your own stimulus and add instantiations of other
> models as necessary.

Ok, that's what I get from the Aldec or Lattice ispLever tools.  I'll
have to look at EMACs sometime soon.  Can it be used to do pretty
print formatting on VHDL files?

Rick