Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
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.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
I am using the view() function to open an ascii file from the shell, but it opens the file in the form/window in Virtuoso looking at the tail end of the file. EG if the ascii file is larger than the viewing window, the contents scroll down to the end of the file. Is there a way to use view() to open an ascii file but have the first view in the Virtuoso window remain at the head end of the file so the user can then scroll down instead of up?
Also, how can we create a path to write to a file location and pull from a specified path location by getting a path string from dbFullPath() and modifying it?
I am creating a new file using the cell name retrieved from geGetEditCellView()->cellName, but want to write to the same path location returned by dbFullPath() - with the exception of the last directory location.
For example, dbFullPath() returns ".../MyLibrary/MyLayout/layout/layout.cdb"
I create a file called "MyLayout_newfile" and want to write to ".../MyLibrary/MyLayout/MyLayout_newfile"
How do I truncate the end of the path returned by dbFullPath() - losing the "/layout/layout.cdb" portion?
What version are you using? The view() function doesn't do that for me - it shows the beginning of the file - the case it wouldn't by default is if you are passing t as the fourth argument to view(), and then updating the file after initially viewing it (the fourth argument is the auto-update flag, to "tail" the file live).
For your second question, I guess you're after geGetEditCellView()~>cell~>writePath
Given any path like /a/b/c/d/e, you can use the following:
path="/a/b/c/d/e"rindex(path "/") "/e"substring(path 1 strlen(path) - strlen(rindex(path "/"))) "/a/b/c/d"
In reply to Andrew Beckett:
My apologies and thanks again Andrew.
I am using v 5.1.41, and I think you are correct about the autoUpdate being responsible for this. When I use view(MyLayout_newfile), the form/window opens with the correct title, but is blank. So I was following the view() call with hiEnableUpdateWindowCB(), and this updated the window with the file contents, but scrolled to the tail (almost every time but for some reason not every time...and did not matter if the file already existed or not).
So this begs the question, how do I get my file contents to load in the window without forcing it with the hiEnableUpdateWindowCB() func?
And - geGetEditCellView()->cell->writePath is just what I wanted - thanks!
In reply to jaleco:
I don't really see why you should have to use hiEnableUpdateWindowCB(). Presumably you haven't finished writing to the file before you view it? Could you make sure the file is written, the output port closed, and then view it?
Otherwise there's also hiScrollWindowToIndex(hiGetCurrentWindow() 0) which could be used to scroll back to the top - but that sounds clunky...
Yes, it is possible the view() func is trying to load a file before it is written.
Here is more sample code:
ipcBeginProcess(strcat("shellscript" MyLayout_newfile)) ; creates output ascii file MyLayout_newfile_out in shell env
What code can I use to make sure the file is written, and the output port closed before viewing it?
In reply to dmay:
FYI after experimentation, I am currently using :
ipcKillProcess(ipcBeginProcess(strcat("myshellscript " MyLayout_newfile)))
This seems to work, but takes several seconds (5-10) to return the final viewing window, whereas the hiEnableUpdateWindowCB() func had immediate results despite loading in the file in tail view.
ipcCloseProcess(ipcBeginProcess(same as above) and ipcWait(ipcBeginProcess(same as above) did not work....
The delay of the ipcKillProcess(ipcBeginProcess()) is frustrating enough to consider (while() or until()) creating a comment popup form telling the user that background processes are running...tic tic tic... until they complete, then delete the comment form before displaying the file view window.
I don't think ipcKillProcess is what you want. Surely ipcWait(ipcBeginProcess(...)) is what you want.
Or you could use the optional exit callback on ipcBeginProcess() - 6th argument I think - to do this.
ipcWait(ipcBeginProcess(...)) never returns....and keeps my Virtuoso session suspended in the meantime until I kill the icfb process at the shell.
But it does usefully (!) display the following in the CIW:
"Waiting for ipc: [id#] to terminate"
over and over again....
I do not see an exit callback argument on ipcBeginProcess()....there is an optional [tsu_postFunc] argument - is that it? If so, can you suggest what to use for this?
I think the problem I have is in the shell script, not in the SKILL code. The shell script was written to write to a file output but also to the shell, and the output to the shell is unable to complete its operation...this is what I can surmise. So until I can rewrite the shell script to avoid shell output, I will rely on the ipcKillProcess() func and then test ipcWait() once more.
Thanks again for your help.
The postFunc arg is the one I meant, but it's definitely not going to help if the child process is not actually exiting. That's the problem you have to solve.
The challenge with using your ipcKillProcess() approach is that you are extremely susceptible to the time it takes to run. If the child process takes slightly too long, you may have killed it before it did anything yet...
The horribly sloppy way of solving this is to:
Or fix the script and spend the rest of the time that you would have spent implementing and debugging the above in the pub.
Thanks again for the info.
I will opt for fixing the script and a Bass!