Stats

  • Locked Locked
  • Replies 3
  • Subscribers 64
  • Views 16405
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

verilogams generate-for loop with analog behavioural block

olalivier

Hi there,

I've been struggling for 2 days in an attempt to write an analog memory... The problem is pretty easy, I need an analog memory with a variable depth to study the influence of the number of sample in a low pass filter. My idea was to write a parametric memory with the width/depth as a parameter. Then use this parameter instantiate multiple memory analog bits. The memory bits are, of course, vams blocks I wrote earlier. 

Here is the generate-for loop : 

genvar i;
for(i=0; i<7; i=i+1) begin
memoire_bit #(.r_switch_on(r_switch_on), .r_switch_off(r_switch_off), .cmem(cmem))
m [7:0] (.vin(vin), .vout(vout), .sample(sample_int[i]), .read(read));
end

When doing this, the hierarchy editor does not see the memory_bit block and ams simulator throws an error 

xmelab: *F,OSDINF (/scratch/electro/lemaire/micro/ic6/ams/035/xtract/diane/memoire_extensible/verilogams/verilog.vams,39|6): instance 'memoire_extensible_sim.I8@memoire_extensible<module>.genblk1[0].m' of design unit 'memoire_bit' is a leaf instance and is unresolved in cellview 'diane.memoire_extensible:verilogams'. Ensure that the design unit is either pre-compiled or its corresponding text file is specified for compilation. Also, check the binding for this instance in Cadence Hierarchy Editor to confirm if it is set to externalHDL or addStopPoint or if nlAction is set to 'stop' for the specified instance.

If I manually unroll the loop with something like this 


memoire_bit #(.r_switch_on(r_switch_on), .r_switch_off(r_switch_off), .cmem(cmem))
m0 (.vin(vin), .vout(vout), .sample(sample_int[0]), .read(read));
memoire_bit #(.r_switch_on(r_switch_on), .r_switch_off(r_switch_off), .cmem(cmem))
m1 (.vin(vin), .vout(vout), .sample(sample_int[1]), .read(read));
memoire_bit #(.r_switch_on(r_switch_on), .r_switch_off(r_switch_off), .cmem(cmem))
m2 (.vin(vin), .vout(vout), .sample(sample_int[2]), .read(read));
memoire_bit #(.r_switch_on(r_switch_on), .r_switch_off(r_switch_off), .cmem(cmem))
m3 (.vin(vin), .vout(vout), .sample(sample_int[3]), .read(read));
memoire_bit #(.r_switch_on(r_switch_on), .r_switch_off(r_switch_off), .cmem(cmem))
m4 (.vin(vin), .vout(vout), .sample(sample_int[4]), .read(read));
memoire_bit #(.r_switch_on(r_switch_on), .r_switch_off(r_switch_off), .cmem(cmem))
m5 (.vin(vin), .vout(vout), .sample(sample_int[5]), .read(read));
memoire_bit #(.r_switch_on(r_switch_on), .r_switch_off(r_switch_off), .cmem(cmem))
m6 (.vin(vin), .vout(vout), .sample(sample_int[6]), .read(read));
memoire_bit #(.r_switch_on(r_switch_on), .r_switch_off(r_switch_off), .cmem(cmem))
m7 (.vin(vin), .vout(vout), .sample(sample_int[7]), .read(read));

then the hierarchy editor sees the memory_bit and everything below, simulation starts and gives expected result.

I've been trying to understand why such a so simple and straight forward thing does not work and what I was doing wrong and, finally, reading the doc I found 

​

Specifying Analog Instances Inside Generate Statements

[...]

Currently, the following is not supported:

  • Analog behavioral block inside the generate statement
  • Declaration of local parameters and nets
  • User-defined functions

Can you please tell me if there's a workaround to fix this issue ?

my conf : 

* ic618

* xcelium 2003

* spectre 191

  • This went into moderation because the repeated text triggered the automated spam detection. Once you'd confirmed it was genuine, it came to me as a moderator to approve, which I then did - clearly it's not spam, but repeated text is a common signature of spam (and believe me, I've had to deal with quite a few genuine spam attacks over the years) - my apologies for it being held up.

    Anyway, the issue with hierarchy within generate blocks (or genvar in this case) is that the hierarchy editor and netlister traversal needs to have a representation to allow it to work out what the underlying block is to be netlisted. Given that depending on the parameter value that affects the expansion, there may be memoire_bit present (or not), it can't produce a representation in the database which captures that - strictly it's not known until run-time (when the simulator elaborates the design) what is within the block, and that variable content cannot be stored within OpenAccess representation. This is a known limitation that is (I believe) documented.

    The workaround is to reference the Verilog-AMS representation of memoire_bit as an external file via the Simulation->Options menu in ADE. The fact that it doesn't show up in the hierarchy editor doesn't matter, because you're just telling the simulator to include the lower level directly (yes, I know it's a pain, but luckily this happens fairly rarely).

    Regards,

    Andrew.

  • in reply to Andrew Beckett

    Hi Andrew and thank you very much for your answer. I feel like I understand your answer but in the same I don't really get why it's working that way. We can imagine that something like 

    parameter integer width = 8 from [1:inf);

    to prevent the instance in the generate loop to "not exist"

    Anyway, I tried your workaround and it works perfectly fine. 

    Thank you very much.

    regards, 

    Olivier 

  • in reply to olalivier

    Hi Olivier,

    The issue is that as soon as you have a generate/genvar type construct, the hierarchical content of the cell is variable. Whilst you can imagine in specific cases we could be sure what is underneath the cell, it's hard to determine that until you elaborate the design - and we need to know what is in the design for the netlist to be able to traverse the hierarchy. The variable/parameterised nature of the verilog code cannot be represented in the database used to contain the structure (and even if it did, we'd have to know what variants were used), so essentially we don't know what's underneath the design in order to netlist it.

    In the past (in some of the older AMS netlisting solutions) we used to try to traverse the hierarchy but it was rather inconsistent and sometimes it ended up with the wrong representation which meant that the results were wrong - so we play safe now and require you to add the reference yourself.

    You can also workaround it by having an unwound instance somewhere in the module - outside of the generated block. That's not always very convenient though. Glad the workaround worked though!

    Regards,

    Andrew.

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.