Re: error in 7.3.1

Ken -
I know I had noticed this before and thought there was something
on the reflector or in Mantis, but I can't find it now.  Reviewing
the "paramsets" proposal, I see that I did a poor job of copying
the material.

One minor point that doesn't really defend my error: any module that
is defined but not instantiated is a top-level module (per 7.1.1),
and some (most?) tools give it an instance name that is the same as
the module name.

Thinking a little further about how this information gets used:
if one had
   module mixer;
     semico250nmCMOS process;
     mix_block mix1(vdd, vss, b1, lo, rfin, rfout);
     mix_bias bias1(vdd, vss, b1);
     oscillator lo1(vdd, vss, b1, lo);
   endmodule
and this module was the top-level module, then all the transistors
inside mix1 (etc) could reference process.tox.

However, now suppose we have a power amplifier (PA) done in
semico500nmGAAS and we try to put both the mixer and the PA in one
system-level module.  Then the transistors in mix1 should be
referencing mixer.process (and the PA devices need to reference
pa.process).

I'll mention here a suggestion from an SV reflector: that the
process constants should actually be set up in a "package"
(though V-AMS doesn't have packages yet).

-Geoffrey


Ken Kundert wrote:
> Martin,
>     I actually was looking at the published LRM rather than the latest
> version, so it might have been fixed already.
> 
> However, I found a new problem. This time in section the example of
> section 7.3.1 (page 138 of published LRM).
> 
> In this example a module is defined called semicoCMOS, and then a
> several hierarchical references are made to it. But this is wrong. You
> cannot reference a module definition. You must reference an instance of
> a module. So, this example needs to be modified in two ways. First, the
> semicoCMOS module must be instantiated. Second, the references should be
> modified so they refer to the instance rather than the module definition.
> 
> -Ken
> 
> Martin O'Leary wrote:
>> My recollection is that at one of the meetings this year, we discussed
>> this issue and agreed to remove this phrase so I agree with Ken on this.
>> I guess the note was overlooked.
>> Thanks,
>> --Martin
>>
>> -----Original Message-----
>> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
>> Behalf Of Ken Kundert
>> Sent: Monday, October 01, 2007 5:21 PM
>> To: verilog-AMS LRM Committee
>> Subject: Section 7.5: Hierarchical names
>>
>> On the top of page 148 in the section on hierarchical names, the LRM 2.2
>> says:
>>
>> From within an analog block, it is possible to use hierarchical name
>> referencing to access signals on an external branch, but not external
>> analog variables or parameters.
>>
>> There is no reason why parameter need to be included in this
>> restriction, and it would be nice to be able to have global access to
>> parameters and localparameters. Can we remove the phrase "or
>> parameters"?
>>
>> -Ken
>>
>> --
>> This message has been scanned for viruses and dangerous content by
>> MailScanner, and is believed to be clean.
>>
>>
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.