Modelsim PE vs. Aldec Active-HDL (PE)

Sat Mar 06, 2010 6:41 pm   

On Mar 5, 4:53 pm, Andy Peters <goo...@latke.net> wrote:

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


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

Sun Mar 07, 2010 1:44 am   

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


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.


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

Sun Mar 07, 2010 3:26 am   

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.


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 agree


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

Sun Mar 07, 2010 2:08 pm   

On Sat, 6 Mar 2010 17:26:24 -0800 (PST), KJ <kkjennings_at_sbcglobal.net> wrote:


You can't keep source files in separate libraries - separate folders, yes,
hence (I presume) your quotes around 'libraries'.

While I do that, I also tend to use a VHDL library structure that reflects the
same source folder structure and design intent.

Except when tool bugs prevent it.

It's really mostly habit, a satisfactory (to me) way of working acquired back in
my Modula-2 days. I'm not making wild claims that it's better in any substantial
way, but VHDL was designed to allow compilation into separate libraries...

Speculating why, it would presumably have allowed compiled libraries to have
been re-used across multiple projects, in the days when compilation and
synthesis were expensive operations. Nowadays, that is trivially unimportant,
except for the highly optimised treatments given to standard libraries.

Tools could make use of it for distributing IP as compiled libraries instead of
source, but they don't...

.... aah, that must be it - I'm just waiting for the tools to catch up! ;-)

- Brian

Mon Mar 08, 2010 12:53 pm   

rickman <gnuarm_at_gmail.com> writes:


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


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

Mon Mar 08, 2010 1:04 pm   

KJ <kkjennings_at_sbcglobal.net> writes:


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.


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


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


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


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

Cheers,
Martin

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

Mon Mar 08, 2010 8:51 pm   

On Mar 6, 9:41 am, KJ <kkjenni...@sbcglobal.net> wrote:

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.


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


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).


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

Mon Mar 08, 2010 10:32 pm   

On Mar 8, 6:53 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

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

Mon Mar 08, 2010 10:34 pm   

On Mar 8, 7:04 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

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

Rick

Mon Mar 08, 2010 11:40 pm   

On Mar 8, 1:32 pm, rickman <gnu...@gmail.com> wrote:

It will create a skeleton for you.


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

Tue Mar 09, 2010 1:38 am   

On Mar 8, 4:40 pm, Andy Peters <goo...@latke.net> wrote:

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

Tue Mar 09, 2010 9:17 am   

rickman <gnuarm_at_gmail.com> writes:


Yes, it will "beautify", either the entire buffer or the current
region (using C-c C-b or C-c M-b).

I'm also using Emacs/Gnus writing this message and reading this
newsgroup. I'm using Emacs/Mew for writing E-mail, also writing
Verilog, Common Lisp, Python, C, Java, LaTex, etc., as well as doing
GIT commits, diffs, creating branches, merges, even surfing the web
using w3m. Dired in Emacs provides a great file browser where I can to
bulk editing etc. Whenever I want to perform tedious repetitive
editing tasks I will usually make a small Emacs Lisp function to do it
for me...

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Tue Mar 09, 2010 11:06 am   

rickman <gnuarm_at_gmail.com> writes:


Here's an example:

Given this (for which I typed very few letters due to autocompletion
and other magic):

entity example is

generic (
blah : integer := 5);

port (
clk : in std_logic;
reset : in std_logic;
a : in integer;
b : out integer);

end entity example;

I can "copy-port" and "paste as testbench" to get this (I have done
nothing further to it at all):

< being vhdl paste >

library ieee;
use ieee.std_logic_1164.all;

----------------------------------------------------------------------------------------------------------------------------------

entity tb_example is

end entity tb_example;

----------------------------------------------------------------------------------------------------------------------------------

architecture test of tb_example is

-- component generics
constant blah : integer := 5;

-- component ports
signal clk : std_logic;
signal reset : std_logic;
signal a : integer;
signal b : integer;

-- clock
signal Clk : std_logic := '1';
-- finished?
signal finished : std_logic;

begin -- architecture test

-- component instantiation
DUT: entity work.example
generic map (
blah => blah)
port map (
clk => clk,
reset => reset,
a => a,
b => b);

-- clock generation
Clk <= not Clk after 10 ns when finished /= '1' else '0';

-- waveform generation
WaveGen_Proc: process
begin
finished <= '0';
-- insert signal assignments here
finished <= '1';
report (time'image(now) & " Finished");
wait;
end process WaveGen_Proc;



end architecture test;

----------------------------------------------------------------------------------------------------------------------------------

configuration tb_example_test_cfg of tb_example is
for test
end for;
end tb_example_test_cfg;

----------------------------------------------------------------------------------------------------------------------------------

< end vhdl paste >

I still need to update the vhdl-mode config so that clk doesn't get
defined twice - I broke that at some point, and haven't gone back to
fix it properly, I just delete the line. That feels very lazy, now
I'm admitting it :)

Cheers,
Martin

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

Tue Mar 09, 2010 12:37 pm   

The problem with emacs is you need three knuckles in each finger to
drive it.


The following perl script builds a basic testbench from a *.vhd entity.

http://www.nialstewartdevelopments.co.uk/download/tb_gen.pl


It's not perfect (generics throw it I think, I keep meaning to fix that)
but it's saved me a lot of time.



Nial.

Tue Mar 09, 2010 8:54 pm   

On Mar 9, 4:37 am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:

Remap the caps-lock key to CTRL and you're back to only two
knuckles :)

-a