Help with ASSERT/REPORT

Wed Jul 14, 2010 3:46 pm   

Hi gurus,

Some background: I have a large collection of projects that use common
entities, and each project can be targeted to different hardware platforms.

Each unique project/hardware combination has its own "project_pkg.vhd"
file, which is a package (no body) that mostly contains a bunch of constants.

What I would like to do is, for *some* of the project/hardware
combinations, invoke an ASSERT/REPORT statement that generates a fatal
error, to indicate that this project/hardware combination is not currently
supported (even though the project file exists). The catch is, I'd like
that ASSERT/REPORT to be included in, or triggered by, the
"project_pkg.vhd" file. It does not necessarily need to be *in* the
package itself, just in the file. And no wholesale changes to other files
in the collection.

Now I can't think of any trickery to achieve this. If I declare an entity
at the bottom of the file containing the ASSERT/REPORT, the ASSERT/REPORT
is never elaborated because the entity is never instantiated.

I've also tried adding an entity in another file altogether
(not_supported.vhd) and adding that to the project, but again, it is not
invoked. I can't instantiate the entity anywhere else in the project,
because the files are common to other project/hardware combinations.

Any ideas?
TIA

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Wed Jul 14, 2010 9:07 pm   

On Thu, 15 Jul 2010 00:46:30 +1000, Mark McDougall wrote:


Here's one approach that works for me: Insist that the package has
at least one subprogram or deferred constant in it. That forces
the package also to have a package body, but said package body
can be something that you provide because it's invariant
across projects. Now you're home free, because the package
body can declare a constant (which, of course, is local
to the package body and not exposed to users of the package)
which gets initialized from a function. And that function
can compute all your interesting relationships among
the project parameters, and throw ERROR asserts ad-libitum.
ERROR rather than FATAL, because it's good to report all
the errors you find, not just the first one.

In addition, it can keep track of the assertion
computations and throw a FATAL assertion if any of
them failed. In that way you get to see ALL the interesting
error messages, but still get a fatal end-of-sim (or
end-of-synthesis) at elaboration time.

Finally, the same function can do other informative
REPORTs to display useful information about the
net effect of all the parameters.

Yell again if this doesn't do what you need!
--
Jonathan Bromley

Wed Jul 14, 2010 9:43 pm   

On 7/14/2010 7:46 AM, Mark McDougall wrote:

If you've got a script based build (batch, sh, Makefile, TCL, etc), then
you can just do that checking at the build level rather than trying to
make it work in native VHDL. Might be less kludgey.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

Thu Jul 15, 2010 1:56 am   

Now that just paid for reading this newsgroup this month!

Thanks,

Andy

Thu Jul 15, 2010 2:32 am   

On Jul 14, 6:56 pm, Andy <jonesa...@comcast.net> wrote:

What, the link to "Simple Hack To Get $2000 To Your PayPal Account"
didn't pan out for 'ya?

KJ

Thu Jul 15, 2010 8:44 am   

Jonathan Bromley wrote:


Hmmm... I thought about providing a package body for that one
project/hardware combo, but didn't try it because I was wondering if it
could be done without adding another file to the project... (unfortunately
according to the LRM IIUC it is illegal to follow the package declaration
with the body in the same file) :(

Anyway, this is probably good enough, I'll give it a go. At least I'll
only have to add the one (standard) package body to those project/hardware
combinations that aren't supported!

Thanks for the tip, I'll let you know how it turns out!

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Thu Jul 15, 2010 9:13 am   

Mark McDougall wrote:


Actually, I stand corrected, it can be done. Cool, I can conceivably add
my assert/report by changing only the project_pkg.vhd file. However, in
hindsight I've moved the body into another file anyway.

Thanks again for the tip!

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Thu Jul 15, 2010 8:36 pm   

On Jul 15, 2:44 am, Mark McDougall <ma...@vl.com.au> wrote:

Whatever gave you that idea? You can most certainly have a package and
its body in the same file (most tools require the body to appear
somewhere after the package in that file)! The only issue is that if
you compile the file when only the body was changed, it will update
both package and body in the library, forcing anything that references
the package to need re-compiling. Some tools have options to get
around this.

Andy

Fri Jul 16, 2010 1:45 am   

Andy wrote:


I think I've misinterpreted something... from here...
<http://www.nt-nv.fh-koeln.de/Labor/VhdlEnglish/Kap6/k63.html#UseCla>

"A package body must have the same name as the corresponding package
declaration, can however be placed anywhere within the design and must not
be placed after the package declaration: "

In any case, sorted - thanks!

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266