Sir, I am beginner coder in verilog AMS. Is there a way to implement a semaphore in analog blocks? I try to open/write/close information in files for each instance using %m, but very quickly I run into the 32 max number of mcd.
I tried to add a randomize loop before doing the open/write/close to try releasing the mcd before another instance needs it but this does not seem to work.

Thank you and Regards,
Claude

Ok, this seems to be correct, I did test with more than 32 instances and did not get a fail. It fail for 500+ instances, so the issue is probably in the simulator limit. So assuming that it is simulator, I would still need to find a way to avoid trying to open a file when I am getting close to that limit, any suggestions as to how this could be achieved?

Another odd issue was that one instance seemed to be writing into the file opened for another instance and I thought that the file IDs were open at simulation instance (thus my thinking of 32 limit per simulation run) and descriptors ended up re-used for several instances:

code:
inst_name = $sformat(inst_name, "%m");
handle = $fopen(inst_name,"w");
$fdisplay(handle,"this fdisplay for %m");
$fclose(handle);

output:
xm1.log:
this is fdisplay for xm1
this is fdisplay for xm2

Geoffrey,
Well, yes that is a lot, but the verilog code within the open-close is very small. I was hoping there would be a means of doing it, the alternative of writing to the same file generated 100s MB file.

I am pretty sure about the instance name difference, it is actually a 5+level deep hierarchy that I simplified to xm1 and xm2 for clarity  ;)

My IT mentioned possible issues with multi-thread and multi-cpu that could create file ID collisions and they are looking into my testcase as well.

I also saw a scheduler-like framework with one global instance that would distribute tokens to the instances that are ready towrite, but I wonder if this would work within the analog space (the semaphore did not).

PS: Is there a way to detect whether the current pass in a veriloga code is the converged pass, like $final_step, but for convergence?

Thank you,
Claude

Claude wrote on Nov 8^th, 2012, 2:44pm:

Hi Claude,
I'd like to add that according to the Verilog-AMS LRM (v2.3.1) sec. 9.5.1 "[t]he most significant bit (bit 31) of a multichannel descriptor is reserved and shall always be cleared, limiting an implementation to at most 31 files opened for output via multichannel descriptors."

- B O E

So apparently, I was mis-reading the documentation, there seem to be provision in Verilog-2001 for 2**31 available file descriptors and when specifying:
           $sformat(inst_filename, "EVL_DBG_%m.log");
           // mcd = $fopen("%m"); MCD only 30 channel since now MSB of MCD is reserved to identify multi-channel vs file descriptors
            handle = $fopen(inst_filename, "w"); // Should have 2**31 possibilities
           $fdisplay(handle, "tran %d:%b", handle, handle);
           $debug("tran %d:%b %m", handle, handle);
           $fclose(handle);
           $debug("     --> should be closing %d:%b", handle, handle);
           
           tmp = $fopen(inst_filename, "w");
           $debug("     --> should be able to reuse %d:%b, getting %d:%b", handle, handle, tmp, tmp);
           $fdisplay(tmp, "tran %d:%b", tmp, tmp);
           $fclose(tmp);

I do get results going up to larger number of file ID:

tran -32:-100000 xi0.xi0.xi0.xdd6.xdd0.a_evl_2tak
    --> should be closing -32:-100000
    --> should be able to reuse -32:-100000, getting -33:-100001

This is the odd part, although I closed descriptor '-32', I cannot re-use it

... continues until ...

tran -1030:-10000000110 xi0.xi0.xi15.xi45.xi0.xi25.xmmp1.xmm0.xdsub.a_evl_2tak
    --> should be closing -1030:-10000000110
    --> should be able to reuse -1030:-10000000110, getting -1031:-10000000111
* ERROR * $fopen() failed. There were not any available file descriptors ...

which is expected because my verilog-AMS vendor indicates in its manual that they have set the limit to 999.

So I am starting to wonder if this is not actually working as per Verilog-2001 and I only did not realize that $fclose() is only executed when a step has converged similarly to how $display() is implemented.

If not, then it is a vendor implementation issue. i am also following-up with them, but hoped someone might already know the answer here,

PS: Re-reading the post I realized that we had already discussed the working 500+ open file test, but at some point I went back to multi-channel (as opposed to file descriptor) thinking that it would work better and thus the apparent disconnect, at least now I know exactly why I only have 999 possibilities  ;)

Thank you,
Claude