How to invoke the geSaveAllForm?

Not sure I agree with your assertion that this is not WYSIWYG - lots of tools work this way. Anyway, you can stream out what is in memory - there is a checkbox on the Export Stream form "Stream Out from Virtual Memory" which doesn't require you to save the data before streaming.

I think the function you want is geSaveHier(). This is restricted to a hierarchy - it's not actually the same as the one from exiting virtuoso as that looks for anything modified and is not restricted to a specific hierarchy (there's no public function for that, but I wrote my own years ago as it's easy enough).

Regards,

Andrew.

Andrew Beckett said:

I think the function you want is geSaveHier(). This is restricted to a hierarchy - it's not actually the same as the one from exiting virtuoso as that looks for anything modified and is not restricted to a specific hierarchy (there's no public function for that, but I wrote my own years ago as it's easy enough).

Yes, that's it!!  It pops up that exact same GUI as XStream Out!  And being restricted to the specific hierarchy I'm going to stream out is exactly what I want.  Thank you!! 

Andrew Beckett said:

Not sure I agree with your assertion that this is not WYSIWYG

Imagine if Microsoft Word printed from the disk rather than from memory.  You make some edits, you save your document, you make some more edits, then you print, but only the edits you saved show up on the printed page.  I think most people would find that counter-intuitive ("what I see" on the screen in front of me is not necessarily "what I get" when I print), which is why all the editors that I am familiar with (MS Paint, GIMP, MS Office Suite, Emacs and Vim) work off what's in memory rather than what's on the disk, so that WYSIWYG!

Andrew Beckett said:

lots of tools work this way.

Maybe so (actually I'm not sure which tools you're thinking of), but in my experience, new users find this behavior surprising.  I've been using Virtuoso since 4.4.3, so I don't even think about it anymore: I just know that, when I stream out, it's going to start up a totally separate process to read what's on the disk (totally ignoring what's on my screen), and use that to produce a GDS or OASIS file.  This is what I have come to expect, so it feels normal to me.... But every time I have to train a new crop of newbies, I am reminded that this behavior is counter-intuitive for the uninitiated. 

Andrew Beckett said:

Anyway, you can stream out what is in memory - there is a checkbox on the Export Stream form "Stream Out from Virtual Memory" which doesn't require you to save the data before streaming.

It seems to me that a couple issues might have been avoided if "Stream Out From Virtual Memory" had always been the default:

1. We wouldn't have this perennial problem where what ends up in the GDS doesn't match what's on the screen. 
2. We wouldn't have this thorny issue of there being certain functions (e.g. le* functions) that I am not allowed to use in pcells, because pcells are streamed out from a totally separate SKILL environment that does not have the full functionality of Virtuoso!  (Does anybody know why it works like that??  I've always wondered....)

It’s probably more of a UNIX-style approach to have a set of cooperating separate processes which are focussed on an individual task. So for a long time there have been external processes that allow the a task such as this to be done in parallel - and even from batch without needing the whole Virtuoso infrastructure to be running to generate a stream file; there are also netlisters that run in the background too. Now of course, multi-threaded applications are a far more common paradigm and parallelism could be achieved that way (although even assuming that this was done, there would need to be some locking to prevent database changes in memory during a stream out; that’s also glossing over the frankly enormous task of making the whole of Virtuoso thread-safe).

The stream out from Virtual memory is a relatively recent addition (it’s still been there for some time), and not the default because we have to preserve existing default behaviour - and some customers actually want to ensure that the data gets saved on disk because otherwise you can end up verifying a design - effectively taping out the stream file for manufacture, but accidentally not save the database. It’s always very hard to change defaults when you have a widespread user base; it’s never going to be OK to change such a default unilaterally for all customers.

The restrictions on available functions in pcells is longstanding, and not just because of the stream interface. Some of the physical verification tools could read the database directly (e.g. Dracula, Diva, Assura etc) and if these are running in batch (which makes sense, because you may want to run on a remote machine), they’d have to have access to the whole of Virtuoso if arbitrary SKILL were needed. Similarly the ITKDB capability where applications can also interface to the database using C code - this also provides database access only rather than the whole of Virtuoso. Historically we used to even have multiple different executables which had different capabilities to try to optimise memory use when memory was far more expensive than it is nowadays (we now have a single virtuoso executable, but we used to have lots of different variants in the past).

So the reasons are historical, infrastructural, and changing it is not as simple as it might appear.

Regards,

Andrew.

It’s probably more of a UNIX-style approach to have a set of cooperating separate processes which are focussed on an individual task. So for a long time there have been external processes that allow the a task such as this to be done in parallel - and even from batch without needing the whole Virtuoso infrastructure to be running to generate a stream file; there are also netlisters that run in the background too. Now of course, multi-threaded applications are a far more common paradigm and parallelism could be achieved that way (although even assuming that this was done, there would need to be some locking to prevent database changes in memory during a stream out; that’s also glossing over the frankly enormous task of making the whole of Virtuoso thread-safe).

The stream out from Virtual memory is a relatively recent addition (it’s still been there for some time), and not the default because we have to preserve existing default behaviour - and some customers actually want to ensure that the data gets saved on disk because otherwise you can end up verifying a design - effectively taping out the stream file for manufacture, but accidentally not save the database. It’s always very hard to change defaults when you have a widespread user base; it’s never going to be OK to change such a default unilaterally for all customers.

The restrictions on available functions in pcells is longstanding, and not just because of the stream interface. Some of the physical verification tools could read the database directly (e.g. Dracula, Diva, Assura etc) and if these are running in batch (which makes sense, because you may want to run on a remote machine), they’d have to have access to the whole of Virtuoso if arbitrary SKILL were needed. Similarly the ITKDB capability where applications can also interface to the database using C code - this also provides database access only rather than the whole of Virtuoso. Historically we used to even have multiple different executables which had different capabilities to try to optimise memory use when memory was far more expensive than it is nowadays (we now have a single virtuoso executable, but we used to have lots of different variants in the past).

So the reasons are historical, infrastructural, and changing it is not as simple as it might appear.

Regards,

Andrew.

Andrew Beckett said:

for a long time there have been external processes that allow the a task such as this to be done in parallel

Oh yeah, like in this thread.  I had forgotten about that use case..... 

Andrew Beckett said:

Now of course, multi-threaded applications are a far more common paradigm and parallelism could be achieved that way (although even assuming that this was done, there would need to be some locking to prevent database changes in memory during a stream out; that’s also glossing over the frankly enormous task of making the whole of Virtuoso thread-safe).

Andrew Beckett said:

The stream out from Virtual memory is a relatively recent addition (it’s still been there for some time), and not the default because we have to preserve existing default behaviour - and some customers actually want to ensure that the data gets saved on disk because otherwise you can end up verifying a design - effectively taping out the stream file for manufacture, but accidentally not save the database.

Yeah, that's what we're afraid of in my organization--that, and the fact that nobody I know streams out from VM for tapeout!  But it's really attractive to have all the SKILL functions in Virtuoso available for pcells....  I should start a new thread to discuss the pros and cons of streaming out from VM. 

Andrew Beckett said:

So the reasons are historical, infrastructural, and changing it is not as simple as it might appear.

Thank you for the detailed summary.  It's wonderful to be able to get this insider's perspective!