Forums

Active HDL Entity Retention

Started by Rick C September 25, 2020
I have multiple entities in a file.  I renamed one of them.  The design bro=
wser now shows both the old entity and the new one.  It won't allow me to d=
o anything with the old entity like delete it.  The name of the old entity =
no longer shows up anywhere in the file.  Any idea how to get rid of this p=
hantom entity? =20

I finally tried deleting the library and recompiling which seems to have do=
ne the trick.  Seems like an extreme measure to clean up a library of old c=
rap.  Any idea why that is needed?=20

--=20

  Rick C.

  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
On Friday, September 25, 2020 at 11:31:57 AM UTC-6, gnuarm.del...@gmail.com=
 wrote:
> I have multiple entities in a file. I renamed one of them. The design bro=
wser now shows both the old entity and the new one. It won't allow me to do= anything with the old entity like delete it. The name of the old entity no= longer shows up anywhere in the file. Any idea how to get rid of this phan= tom entity?=20
>=20 > I finally tried deleting the library and recompiling which seems to have =
done the trick. Seems like an extreme measure to clean up a library of old = crap. Any idea why that is needed?=20
>=20 > --=20 >=20 > Rick C.=20 >=20 > - Get 1,000 miles of free Supercharging=20 > - Tesla referral code - https://ts.la/richard11209
This is typical for probably all the EDA tools. I use VCS, which is a lot = nicer than Aldec, and I still have to wipe out old files sometimes. Someti= mes the simulation doesn't change even though I've modified the source code= , and I have to use a Unix alias I designed for the task to wipe out all li= braries and archived files so it will start anew.
On Sunday, September 27, 2020 at 2:57:13 PM UTC-4, Kevin Neilson wrote:
> On Friday, September 25, 2020 at 11:31:57 AM UTC-6, gnuarm.del...@gmail.c=
om wrote:
> > I have multiple entities in a file. I renamed one of them. The design b=
rowser now shows both the old entity and the new one. It won't allow me to = do anything with the old entity like delete it. The name of the old entity = no longer shows up anywhere in the file. Any idea how to get rid of this ph= antom entity?=20
> >=20 > > I finally tried deleting the library and recompiling which seems to hav=
e done the trick. Seems like an extreme measure to clean up a library of ol= d crap. Any idea why that is needed?=20
> >=20 > > --=20 > >=20 > > Rick C.=20 > >=20 > > - Get 1,000 miles of free Supercharging=20 > > - Tesla referral code - https://ts.la/richard11209 >=20 > This is typical for probably all the EDA tools. I use VCS, which is a lo=
t nicer than Aldec, and I still have to wipe out old files sometimes. Some= times the simulation doesn't change even though I've modified the source co= de, and I have to use a Unix alias I designed for the task to wipe out all = libraries and archived files so it will start anew. That's just strange. Another issue I have is because I won't bury my sourc= e files in their tool project hierarchy. So every time I change a file I h= ave to copy it to their directory. That's not a huge hassle, but the tool = seems to know I'm doing this and knows when the original files change. The= y will flag the local (to the tool) copy as out of date... but typically no= t until I've already copied it into the tool directory and compiled and ev= en started running it. Or I will have the lower level files compiling with= out errors and the working on the next level up when it tells me the lower = level files is out of data. =20 Goofy damn software. I wish it would just work with the files I give it ra= ther than making a copy in the mess of directories they create.=20 --=20 Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
The library on all tools keeps the old entities around until you delete the library or 
delete specific items from the library (if the tool allows this).   

As a practice, you should be deleting your library on a regular basis - for
example before any regression run.   The reasoning is below.   

Before I go there, one thing that may make ActiveHDL easier to use is to use the
OSVVM scripting environment (it is free, open source).   The OSVVM scripting 
environment switches ActiveHDL to tcl mode and adds a layer of procedures in 
front of all the tool commands - this way we can create a uniform set of commands 
to create libraries, analyze (compile) designs, and run simulations that works on 
different simulators (currently ActiveHDL, VsimSA, RivieraPro, ModelSim, and
QuestaSim).   Scripts for GHDL are a work in progress and are working, but a 
challenge to use.  You can find it at:  https://github.com/OSVVM/OSVVM-Scripts.
I should note though currently they just use VHDL-2008 - which is 
ok for RTL and good for testbench. 

You can use the OSVVM scripting environment to just run scripts, run
interactively from the command line if you like this, or just to simplify
the set up of your initial ActiveHDL environment.   It also allows you to
easily switch between the supported simulators - which hopefully we
will be expanding some time later this year or early next.   

Now, why do I need to delete libraries on a regular basis?
One rule you may be aware of is that VHDL's default binding always selects 
the most recently analyzed (compiled) design unit (entity, architecture, ...).   
However the weasel words were left out.  What it  should say is default binding
always selects the most recently successfully analyzed design unit.  

This means that if you leave an old architecture laying around in your library
as you run regressions and the current architecture fails to analyze, it will
simulate the old one.  

Hence, you need to delete your libraries before you make regression runs.

Cheers,
Jim

On Monday, September 28, 2020 at 8:56:52 AM UTC-4, Jim Lewis wrote:
> The library on all tools keeps the old entities around until you delete t=
he library or=20
> delete specific items from the library (if the tool allows this). =20 >=20 > As a practice, you should be deleting your library on a regular basis - f=
or
> example before any regression run. The reasoning is below. =20 >=20 > Before I go there, one thing that may make ActiveHDL easier to use is to =
use the
> OSVVM scripting environment (it is free, open source). The OSVVM script=
ing=20
> environment switches ActiveHDL to tcl mode and adds a layer of procedures=
in=20
> front of all the tool commands - this way we can create a uniform set of =
commands=20
> to create libraries, analyze (compile) designs, and run simulations that =
works on=20
> different simulators (currently ActiveHDL, VsimSA, RivieraPro, ModelSim, =
and
> QuestaSim). Scripts for GHDL are a work in progress and are working, bu=
t a=20
> challenge to use. You can find it at: https://github.com/OSVVM/OSVVM-Sc=
ripts.
> I should note though currently they just use VHDL-2008 - which is=20 > ok for RTL and good for testbench.=20 >=20 > You can use the OSVVM scripting environment to just run scripts, run > interactively from the command line if you like this, or just to simplify > the set up of your initial ActiveHDL environment. It also allows you to > easily switch between the supported simulators - which hopefully we > will be expanding some time later this year or early next. =20 >=20 > Now, why do I need to delete libraries on a regular basis? > One rule you may be aware of is that VHDL's default binding always select=
s=20
> the most recently analyzed (compiled) design unit (entity, architecture, =
...). =20
> However the weasel words were left out. What it should say is default b=
inding
> always selects the most recently successfully analyzed design unit. =20 >=20 > This means that if you leave an old architecture laying around in your li=
brary
> as you run regressions and the current architecture fails to analyze, it =
will
> simulate the old one. =20 >=20 > Hence, you need to delete your libraries before you make regression runs.
I'm not up on my VHDL terminology so I'm not clear on what is meant by "ana= lyze", but I looked it up and that seems pretty clear (maybe there are some= subtleties not explained in two or three paragraphs). Doesn't the tool in= form you that the architecture is out of date vs. the source that was last = compiled? Would the compile errors not be obvious? =20 I'm working with the GUI which flags each file as having compile errors, be= ing out of date or presently compiled and in the library. I believe it com= plains if I try to simulate with old libraries even if I can ignore the war= nings.=20 --=20 Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209