Re: [sv-bc] why is it ILLEGAL ?

hi steve-

your point is well taken. i do agree that in certain scenarios, it can
*at times* be harmful, and depending on the nature of the mismatch you
end up encountering in your RTL simulation, can require several hours of
debugging to root-cause the issue. but then again, at times, it could be
frustrating, and here is why.

please understand that i am not trying to do any *intentional*
declarations of the same variable. it is *accidental*, and a consequence
of many factors. assume this hypothetical scenario where you have, at
the top level, instances of the following blocks. i will keep it simple.


	CPU <---> L2$ <---> Memory Controller <---> DRAM


you also have stubs and monitors built around every interface. let me
make it slightly more complicated! at the block level, you can have 2
versions of the same behavioral code, one for SW and one for HW
accelerator. that means codes are guarded with `ifdef / `ifndef.

typical verification strategy is that each block is verified first
within a stand-alone testing (SAT) environment, and then integrated into
what is known as the full-chip / top level.

now clock generators typically come from an external module
(specifically PLL), and so you have "wire" declarations going on all
over the place. note that the SAT level blocks can and will possibly
have it's own clock. now if you integrate the whole thing, even though
you have the wire declaration at 'top' level to get the actual clock
from the PLL, the identical but additional wire declaration of the
*same* clock name (coming from the SAT) will justifiably cause
compilation to fail.

and that is only a simple scenario. you can further assume there could
be a whole other bunch of other wires that happen to be common, but a
verification engineer like myself wouldn't know, and i don't need to.
and so, if i have a linting tool to validate my design first (checking
for syntax and semantics), and then parse the design to a simulator, i
wouldn't likely know the status of the build process until it fails at
the parsing stage (which could inherently take several hours, depending
on how big/complex the design is and how exhaustive the linting tool
does it's job).

i ran into this precise issue several times and it took me several (> 12
to be exact) iterations to get it working finally! :(

what you have declared below is the scenario i am talking about.
sometimes, the 'top' level module can be so large (it instantiates many
blocks, stubs and monitors) that one wouldn't know if some wire has
actually been declared in the *same* file / scope or not, not to mention
if it has been declared originally at the SAT level.

thanks,
-nasim



Steven Sharp wrote On 01/04/06 04:05 PM,:
> Nasim,
> 
> You are assuming that just because the user declared the same identifier
> twice with the same type, that they intended this to be a single object.
> This may not be true, in which case you would be allowing the user to
> make a serious mistake.
> 
> Consider the realistic case of a module that is too large to easily
> keep track of all the identifiers declared in it.  You may need to go
> back and modify it later, adding a new net in the process.  If you
> happen to use the same name as another net that you already declared,
> and the compiler doesn't stop you, then you have accidentally shorted
> this new net to the old one.  You could spend a lot of hours debugging
> to figure out why your design isn't working the way you wanted.
> 
> Allowing redundant declarations of the same object does not provide you
> any extra functionality, and causes you harm if you actually intended
> to declare separate objects.
> 
> Steven Sharp
> sharp@cadence.com
> 

-- 
-----------------------------------------------------------------
Nasim Hussain      | Life is short,   ---     _ o     _~o     _ o
UltraSPARC Verif.  |   go wherever  ----    _`\<,   _`\<,   _`\<,
SUN Microsystems   |     you want     ---  ( )/( ) ( )/( ) ( )/( )
work:(408)720-4927 |
home:(650)967-7730 |