The Designer's Guide Community Forum

The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl
Design Languages >> Verilog-AMS >> fatal internal errors
https://designers-guide.org/forum/YaBB.pl?num=1190736298

Message started by Eugene on Sep 25^th, 2007, 9:04am

Title: fatal internal errors
Post by Eugene on Sep 25^th, 2007, 9:04am

I'm trying to do functional verification of a full mixed signal chip. I'm using wreal pins in the Cadence environment for the analog blocks to avoid slowing the simulation down with the analog simulator. The analog blocks work fine by themselves and in small test benches. However, in larger test benches we encounter fatal internal errors during elaboration that produce no hints as to what's causing the problem. The only clue we have is that when we disconnect certain wreal pins, the simulation runs. This is not a case of wreal connected to a non-wreal. That error produces a useful error message. This error message is pretty useless. Has anyone else encountered this problem, and hopefully solved it?

Title: Re: fatal internal errors
Post by Stefan on Sep 25^th, 2007, 9:40am

Hi Eugene,
we're also doing that stuff (see our Paper on the las BMAS conference).
We didn't encounter such problems, although we have found several other bugs with wreal datatypes.
If it's possible for you, I'd love to see how you do things.
If you could provide me with a testcase showing your error, I'd be glad to check it.
Regards,

Stefan Joeres
University of Technology, Aachen, Germany

Title: Re: fatal internal errors
Post by rajdeep on Sep 26^th, 2007, 4:55am

Eugene wrote on Sep 25^th, 2007, 9:04am:

I'm using wreal pins in the Cadence environment for the analog blocks to avoid slowing the simulation down with the analog simulator.

Can anyone explain how come using wreal avoid reducing simulation speed? :o

Title: Re: fatal internal errors
Post by Eugene on Sep 26^th, 2007, 8:40am

Stefan,
Thanks for the response. I am familiar with your BMAS paper. I saw your presentation. I'm looking forward to trying some of your ideas on our next project. I cannot send you a test case because the full circuit is proprietary and smaller test cases do not exhibit the problem. We recently found a magical solution to the problem. I say "magical" because we have no why it works, which is not very comforting.

To answer rajdeep's question, we are using wreals to model analog blocks with otherwise VerilogD code. VerilogD refers to pure Verilog, as opposed to VerilogA or VerilogAMS. As long as we use wreals to pass real numbers between models and do not use any "analog" blocks in our VerilogAMS code, the simulation is event driven; it is not iteratively solving non-linear algebraic equations at each time step like SPICE or Spectre do. It is also not squeezing the time steps down to control numerical accuracy. The simulation speed is closer to that of a purely digital simulation. To put it another way, wreals have no units like volts or amps. They are just real numbers. Thus, there's no Kirkoff laws to enforce. The wreal models of analog blocks are usually fairly simple and used only to check functionality, not performance; the models usually do not include impairments such as noise and nonlinearity.

The problem with wreals is that they only let you pass one number one way on a pin. There is no high impedance wreal state. That means you cannot resolve analog signal contention and you cannot have bidirectional (i.e. inout) pins. Analog signal contention refers to having multiple wreal outputs drive a common node. This situation arises often in RF systems where several RF front end receivers share a common baseband analog filter. Ideally only one front end is powered at a time. However, you'd like a graceful way to detect when more than one accidently turns on. The bidirectional problem arises because we must often re-use pins at the chip boundary. The "one number" limitation means that you cannot implement baseband equivalent models of RF circuits with pin-accurate models.

We have no work around for the baseband equivalent problem but we have some ugly tricks for getting around the other two problems. These tricks are ugly because they impact the schematics and because some of the code must be changed whenever you perform some cut-and-paste operations on your schematic.