Friday, July 20, 2007
The End of InnerLoop
There will be no more blog entries on InnerLoop. After a noble effort by Posedge Software there were not enough users willing to pay for the product. If you like InnerLoop please contact SlickEdit (www.slickedit.com) and ask for e and SystemVerilog support.
So long.
There will be no more blog entries on InnerLoop. After a noble effort by Posedge Software there were not enough users willing to pay for the product. If you like InnerLoop please contact SlickEdit (www.slickedit.com) and ask for e and SystemVerilog support.
So long.
Wednesday, April 11, 2007
Counting Lines in a Project
I can't believe how fast time goes by. It has been a few months since my last post on using InnerLoop. I guess a combination of travel and rushing to get new releases out takes it toll.
Just to get things started again, I'm going to cover something simple today. One of the things nobody seems to know is how many lines of code are in a verification environment. Sure, you can use wc -l to count them but all the files are usually in many places and it's not worth writing a script for such purposes.
InnerLoop now has a linecount command to take care of this automatically. When your project is open just click on the bottom left area of InnerLoop to activate the command box and type: linecount
You will see a new buffer created named LineCountResults.txt with the summary of the project.
There will also be a list of each file with the filename and number of lines of code. Note that the count doesn't include comments. Some people like to count comments since they are important and some do not. This command does not, but I'm sure if you really want to count them just send a message to support@posedgesoft.com and it will be added. Have fun counting your code.
Here's an example:
I can't believe how fast time goes by. It has been a few months since my last post on using InnerLoop. I guess a combination of travel and rushing to get new releases out takes it toll.
Just to get things started again, I'm going to cover something simple today. One of the things nobody seems to know is how many lines of code are in a verification environment. Sure, you can use wc -l to count them but all the files are usually in many places and it's not worth writing a script for such purposes.
InnerLoop now has a linecount command to take care of this automatically. When your project is open just click on the bottom left area of InnerLoop to activate the command box and type: linecount
You will see a new buffer created named LineCountResults.txt with the summary of the project.
There will also be a list of each file with the filename and number of lines of code. Note that the count doesn't include comments. Some people like to count comments since they are important and some do not. This command does not, but I'm sure if you really want to count them just send a message to support@posedgesoft.com and it will be added. Have fun counting your code.
Here's an example:
**************** LINE COUNT RESULTS ****************
WORKSPACE NAME: junk.vpw
REPORT GENERATED: 4/11/2007
TOTAL PROJECTS: 1
TOTAL NUMBER OF FILES: 150
TOTAL LINES OF CODE: 19331
PROJECT NAME: junk.vpj - 150 Files, 19331 Lines
****************************************************
DETAILED RESULTS PER PROJECT & PER FILE:
---------------------------------------
PROJECT NAME: junk.vpj - 150 Files, 19331 Lines
Wednesday, January 03, 2007
Using InnerLoop as the editor in Specview
There are many places in specview that allow uses to edit the e source files that are loaded into specman. The modules window and the sys browser are just 2 examples. I often use the modules window to look at the loaded code and set initial breakpoints before I start running.
Today, during some routine debugging I was looking at some code and was confused because I saw some stuff I thought I had deleted. Unfortunately, after the long Christmas holiday last year seemed like a long time ago and I couldn't remember much. I was frustrated with the black-and-white file viewer that is part of specview so I thought if I did "Edit File" at least vim would come up and I could get some color coding. When I tried to edit the file I just got an xterm with an error message about couldn't exec something, who knows. Then I decided what I really needed was InnerLoop, even thought when I started out I figured this session was so easy I shouldn't really even need InnerLoop.
Looking into the Specman docs I found I could control the editor that is opened by specview using the environment variables SPECMAN_EDITOR or even just EDITOR. I also saw the default was to open /usr/ucb/vi which doesn't even exist on Linux (probably the cause of the error).
After some trial and error I figured out how to get il to open as the editor and load the file and put the cursor on the correct line number as specified by specman. Now I can get a real editor that is built for e instead of a black-and-white file viewer or an error in an xterm.
Here is the setting I used to set SPECMAN_EDITOR
setenv SPECMAN_EDITOR 'il +new $f -#"goto-line $l"'
I like to have a new instance of il so I don't disturb the others I have running. The $f is the filename set by specman and the $l is the line number set by specman.
After this I realized the strange code was actually commented out using code markers (<' and '>).
Give it a try and start using il as the editor with specview.
My next trick is going to be to extract all the e files that are loaded and automatically create an InnerLoop project with these files and load them into InnerLoop directly from specview. For various reasons this is easier than creating the project in other ways to make sure all the correct files are being used.
There are many places in specview that allow uses to edit the e source files that are loaded into specman. The modules window and the sys browser are just 2 examples. I often use the modules window to look at the loaded code and set initial breakpoints before I start running.
Today, during some routine debugging I was looking at some code and was confused because I saw some stuff I thought I had deleted. Unfortunately, after the long Christmas holiday last year seemed like a long time ago and I couldn't remember much. I was frustrated with the black-and-white file viewer that is part of specview so I thought if I did "Edit File" at least vim would come up and I could get some color coding. When I tried to edit the file I just got an xterm with an error message about couldn't exec something, who knows. Then I decided what I really needed was InnerLoop, even thought when I started out I figured this session was so easy I shouldn't really even need InnerLoop.
Looking into the Specman docs I found I could control the editor that is opened by specview using the environment variables SPECMAN_EDITOR or even just EDITOR. I also saw the default was to open /usr/ucb/vi which doesn't even exist on Linux (probably the cause of the error).
After some trial and error I figured out how to get il to open as the editor and load the file and put the cursor on the correct line number as specified by specman. Now I can get a real editor that is built for e instead of a black-and-white file viewer or an error in an xterm.
Here is the setting I used to set SPECMAN_EDITOR
setenv SPECMAN_EDITOR 'il +new $f -#"goto-line $l"'
I like to have a new instance of il so I don't disturb the others I have running. The $f is the filename set by specman and the $l is the line number set by specman.
After this I realized the strange code was actually commented out using code markers (<' and '>).
Give it a try and start using il as the editor with specview.
My next trick is going to be to extract all the e files that are loaded and automatically create an InnerLoop project with these files and load them into InnerLoop directly from specview. For various reasons this is easier than creating the project in other ways to make sure all the correct files are being used.
Tuesday, December 19, 2006
Finding References
Maybe I'm just getting old, but sometimes I don't see the obvious things in life. As you could guess from this blog, I have been using InnerLoop for some time now. One of the most common things I do everyday is to find references to a particular symbol. When I want to see all the places a particular symbol is used I usually start thinking, "where was that thing again?". Then I try to find which file it was in and then use ctrl-/ to find all the references.
I have no idea why I was doing it like this. What I should have been doing was just entering the symbol name in the little box that says "Symbol" in the references toolbar. For some dumb reason maybe I thought this was a read only box, I have no idea. Entering the symbol here immediately finds all the references and I don't have to remember where to find at least one instance of it just so I can hit ctrl-/
I would bet a lot of people have similar troubles with InnerLoop. The tool has lots of useful features, but sometimes it just takes some practice to find the most efficient ways to use it. It takes some experimentation to find all the ways that code can be displayed to get the most from it.
Just in case anybody is as clueless as I am, there is no excuse for not finding references very quickly now.
Maybe I'm just getting old, but sometimes I don't see the obvious things in life. As you could guess from this blog, I have been using InnerLoop for some time now. One of the most common things I do everyday is to find references to a particular symbol. When I want to see all the places a particular symbol is used I usually start thinking, "where was that thing again?". Then I try to find which file it was in and then use ctrl-/ to find all the references.
I have no idea why I was doing it like this. What I should have been doing was just entering the symbol name in the little box that says "Symbol" in the references toolbar. For some dumb reason maybe I thought this was a read only box, I have no idea. Entering the symbol here immediately finds all the references and I don't have to remember where to find at least one instance of it just so I can hit ctrl-/
I would bet a lot of people have similar troubles with InnerLoop. The tool has lots of useful features, but sometimes it just takes some practice to find the most efficient ways to use it. It takes some experimentation to find all the ways that code can be displayed to get the most from it.
Just in case anybody is as clueless as I am, there is no excuse for not finding references very quickly now.
Thursday, December 14, 2006
Backup History
InnerLoop has a very nice feature that keeps a history of the files you edit.
This week I was working on some new features for my project. One of my co-workers recommended a better way to implement something based on a description I provided him. Since he is a very smart guy and usually knows what he's talking about I just started to implement it without too much thinking. I ended up editing about 5 different files with InnerLoop and suddenly realized I wasn't so sure this was the right way to go. Unfortunately, I couldn't just revert to the latest in CVS since I already had a bunch of other changes that I thought were good, but not complete enough or well tested enough to check-in. I really didn't feel like taking out all of today's changes manually.
To bail me out I turned to the backup history in InnerLoop. On the File menu you will find something called "Backup History". If you select this on a particular file you will see a bunch of numbered versions with dates and times. I knew the time I started all my changes and from comparing to CVS which files were changed. Using this backup history I selected a version I thought was before I got into this mess and hit the Diff button. Sure enough, it shows me all the changes I made. All I had to do was undo the changes by either merging them 1 at a time or merging all of them back into my file and things were quickly back to where I started.
I didn't change any configuration related to the Backup History, but if you are interested you can find more options for it on the Tools -> Options -> File Options dialog on the Backup tab.
I'm pretty sure emacs or vim would not have bailed me out of this quite so quickly.
Happy Coding!
InnerLoop has a very nice feature that keeps a history of the files you edit.
This week I was working on some new features for my project. One of my co-workers recommended a better way to implement something based on a description I provided him. Since he is a very smart guy and usually knows what he's talking about I just started to implement it without too much thinking. I ended up editing about 5 different files with InnerLoop and suddenly realized I wasn't so sure this was the right way to go. Unfortunately, I couldn't just revert to the latest in CVS since I already had a bunch of other changes that I thought were good, but not complete enough or well tested enough to check-in. I really didn't feel like taking out all of today's changes manually.
To bail me out I turned to the backup history in InnerLoop. On the File menu you will find something called "Backup History". If you select this on a particular file you will see a bunch of numbered versions with dates and times. I knew the time I started all my changes and from comparing to CVS which files were changed. Using this backup history I selected a version I thought was before I got into this mess and hit the Diff button. Sure enough, it shows me all the changes I made. All I had to do was undo the changes by either merging them 1 at a time or merging all of them back into my file and things were quickly back to where I started.
I didn't change any configuration related to the Backup History, but if you are interested you can find more options for it on the Tools -> Options -> File Options dialog on the Backup tab.
I'm pretty sure emacs or vim would not have bailed me out of this quite so quickly.
Happy Coding!
Wednesday, November 01, 2006
Using CVS
For my daily development projects we are using cvs as a revision control system. I have found InnerLoop to be of great help in this area. As I mentioned in the last post I'm normally working in many different networks and user accounts. With cvs I can checkout the code anywhere using the remote access features and check it back in from anywhere. For me it's a simple as setting the environment variable CVSROOT to the path with the repository and then I set CVS_RSH to ssh and that's it.
No matter where I am I can fire up InnerLoop and do Tools -> Version Control -> Setup and select CVS. There is nothing else to setup.
I found the best way is to work with the cvs repository is to do Tools -> Version Control -> Compare with CVS...
This command allows me to specify a directory with my sandbox. I can select any part of the sandbox or all of it and check the recursive box if I want to descend the tree. InnerLoop will think a bit then display all of the differences between my sandbox and the repository. I can see files I modified, files that somebody else checked in and are newer in the repository, I can see files added that are not in my sandbox, etc. This is a nice graphical view. I used to fish around by doing:
% cvs -n update > t
and then look in t and see what has changed. I also always had to remember to do -d to get new directories, but with InnerLoop it figures all this out automatically.
The nice think is now I can browse the tree in InnerLoop and easily look at the diffs using DIFFzilla, a powerful difference engine, look at the history, and commit and update files. The history view is useful when there are branched involved. The graphical picture is much easier to see than the command line cvs commands.
The key to using cvs over ssh it to make sure the remote machine does not need to ask for your password. I found that InnerLoop will choke if the ssh session requires a password. I have no idea where a password can be entered. They key is to get no password ssh working before you start with InnerLoop and cvs. A simple google search for "ssh no password" will find the needed info to setup both ends so ssh will not ask for a password.
After getting used to InnerLoop for cvs it's hard to remember when I did it all by command line (including the diffs). I guess things were always more difficult in the old days.
For my daily development projects we are using cvs as a revision control system. I have found InnerLoop to be of great help in this area. As I mentioned in the last post I'm normally working in many different networks and user accounts. With cvs I can checkout the code anywhere using the remote access features and check it back in from anywhere. For me it's a simple as setting the environment variable CVSROOT to the path with the repository and then I set CVS_RSH to ssh and that's it.
No matter where I am I can fire up InnerLoop and do Tools -> Version Control -> Setup and select CVS. There is nothing else to setup.
I found the best way is to work with the cvs repository is to do Tools -> Version Control -> Compare with CVS...
This command allows me to specify a directory with my sandbox. I can select any part of the sandbox or all of it and check the recursive box if I want to descend the tree. InnerLoop will think a bit then display all of the differences between my sandbox and the repository. I can see files I modified, files that somebody else checked in and are newer in the repository, I can see files added that are not in my sandbox, etc. This is a nice graphical view. I used to fish around by doing:
% cvs -n update > t
and then look in t and see what has changed. I also always had to remember to do -d to get new directories, but with InnerLoop it figures all this out automatically.
The nice think is now I can browse the tree in InnerLoop and easily look at the diffs using DIFFzilla, a powerful difference engine, look at the history, and commit and update files. The history view is useful when there are branched involved. The graphical picture is much easier to see than the command line cvs commands.
The key to using cvs over ssh it to make sure the remote machine does not need to ask for your password. I found that InnerLoop will choke if the ssh session requires a password. I have no idea where a password can be entered. They key is to get no password ssh working before you start with InnerLoop and cvs. A simple google search for "ssh no password" will find the needed info to setup both ends so ssh will not ask for a password.
After getting used to InnerLoop for cvs it's hard to remember when I did it all by command line (including the diffs). I guess things were always more difficult in the old days.
Monday, October 30, 2006
ftp client
I work in a distributed computing environment. At any particular time I may use one of the linux machines in my home office, I may login to a machine in San Jose or I may need to login to a machine in Isreal depending on what I'm doing. The machines in San Jose and Israel both use my same username and password but the home directories are not the same, they are unique in each place. Sometimes I will also work from my laptop using VMware for linux. Given these 4 unique filesystems I am forced to spend time moving files back and forth depending on the task at hand.
To do this I often turn to another of the useful toolbars (that is hiden by default) in InnerLoop called the ftp client.
To activate it right click on any of the toolbars to bring up the toolbar list and select ftp client. There is also a toolbar called just ftp, but I don't find this one as useful.
Once the toolbar is open hit the button with the green + sign and then hit Add to setup a new profile. Enter the data to connect to the machine you want to reach and then connect. This profile will be saved (even though I don't see it on the pull-down when I come back next time) and when I come back next time I hit the green + sign again and connect.
Once connected I feel like I want to drag-and-drop files back and forth, but that won't work. The key is to right click the mouse and use the upload and download menu items (depending which side you select file or directories on). You can also use the right click to delete files, rename them, create new directories, and more.
Give it a try next time you need to ftp or use ssh to move data back and forth.
I work in a distributed computing environment. At any particular time I may use one of the linux machines in my home office, I may login to a machine in San Jose or I may need to login to a machine in Isreal depending on what I'm doing. The machines in San Jose and Israel both use my same username and password but the home directories are not the same, they are unique in each place. Sometimes I will also work from my laptop using VMware for linux. Given these 4 unique filesystems I am forced to spend time moving files back and forth depending on the task at hand.
To do this I often turn to another of the useful toolbars (that is hiden by default) in InnerLoop called the ftp client.
To activate it right click on any of the toolbars to bring up the toolbar list and select ftp client. There is also a toolbar called just ftp, but I don't find this one as useful.
Once the toolbar is open hit the button with the green + sign and then hit Add to setup a new profile. Enter the data to connect to the machine you want to reach and then connect. This profile will be saved (even though I don't see it on the pull-down when I come back next time) and when I come back next time I hit the green + sign again and connect.
Once connected I feel like I want to drag-and-drop files back and forth, but that won't work. The key is to right click the mouse and use the upload and download menu items (depending which side you select file or directories on). You can also use the right click to delete files, rename them, create new directories, and more.
Give it a try next time you need to ftp or use ssh to move data back and forth.
Thursday, October 05, 2006
Diffing
InnerLoop has an excellent diff cool called DIFFzilla. The name is actually trademarked. You can access it from the Tools -> File Difference menu item.
It can be used to diff just about anything, text files, a directory tree, binary files, and if you have a revision control system setup it can even diff against different versions in the repository. It does a very good job in aligning the files you are diffing to clearly display what is the same and what is not.
One of the cool things about DIFFzilla is you can edit the files right in the diff window. If you see something that needs to be changed there is no reason to go back to the edit window to make change, just change it right in the diff display and save, very cool.
You can also run just the diff engine from the command line. If you like to work at the shell prompt and need to do a diff there is no reason to settle for the unix diff. After 15 years I still forget if the first or the second file has the <> on the diff results when using unix diff. You can run DIFFzilla by doing
% vsdiff file1 file2
If you want to do more complex things just type vsdiff and the configuration dialog will open and you can setup what you want to diff.
Since my brain shuts off sometimes and I resort to old habits I just alias diff to vsdiff.
Give it a try.
InnerLoop has an excellent diff cool called DIFFzilla. The name is actually trademarked. You can access it from the Tools -> File Difference menu item.
It can be used to diff just about anything, text files, a directory tree, binary files, and if you have a revision control system setup it can even diff against different versions in the repository. It does a very good job in aligning the files you are diffing to clearly display what is the same and what is not.
One of the cool things about DIFFzilla is you can edit the files right in the diff window. If you see something that needs to be changed there is no reason to go back to the edit window to make change, just change it right in the diff display and save, very cool.
You can also run just the diff engine from the command line. If you like to work at the shell prompt and need to do a diff there is no reason to settle for the unix diff. After 15 years I still forget if the first or the second file has the <> on the diff results when using unix diff. You can run DIFFzilla by doing
% vsdiff file1 file2
If you want to do more complex things just type vsdiff and the configuration dialog will open and you can setup what you want to diff.
Since my brain shuts off sometimes and I resort to old habits I just alias diff to vsdiff.
Give it a try.
Tuesday, September 26, 2006
3 Editing Tricks
Today I have 3 tricks to improve editing with IL (InnerLoop).
Column Selection
I normally use vi and never learned any way to select columns of text and cut, copy, or insert them. Eventually I learned how to do it with emacs using rectangle command like Ctrl-x r k to kill a rectangle, etc. With InnerLoop it took me some time to figure out how to it. I first tried to switch to emacs key bindings and go back to the keystrokes I knew, but they didn't work. I then found out the secret is to select the text with the right mouse button instead of the left. Using the right mouse button selects a rectangle and you can easily cut or copy it using the buttons at the top. I never would have guessed it.
Tab to Align Code
IL has the ability to correctly indent your code by using the Tab key. I think it's called "smart tab". Say you restructure some code and some lines are now indented too much. Instead of using delete to pull them back to the left you can hit tab and IL will do this for you and set the indenting to the correct amount. I guess the tab is not really a tab in this case since text may move left or right.
Edit Toolbar
One of the toolbars that is not automatically displayed is called "edit". There are two pairs of buttons on this toolbar that are useful to adjust the indent of the code. They are the ones with the orange boxes and blue arrows. If a block of text is selected they will move the code either right or left 1 level of indentation or just 1 space at a time (for fine tuning). There are many times when blocks of code must slide right or left and this is a great way to do it. Turn on this toolbar using View -> Toolbars -> Edit and give it a try.
Today I have 3 tricks to improve editing with IL (InnerLoop).
Column Selection
I normally use vi and never learned any way to select columns of text and cut, copy, or insert them. Eventually I learned how to do it with emacs using rectangle command like Ctrl-x r k to kill a rectangle, etc. With InnerLoop it took me some time to figure out how to it. I first tried to switch to emacs key bindings and go back to the keystrokes I knew, but they didn't work. I then found out the secret is to select the text with the right mouse button instead of the left. Using the right mouse button selects a rectangle and you can easily cut or copy it using the buttons at the top. I never would have guessed it.
Tab to Align Code
IL has the ability to correctly indent your code by using the Tab key. I think it's called "smart tab". Say you restructure some code and some lines are now indented too much. Instead of using delete to pull them back to the left you can hit tab and IL will do this for you and set the indenting to the correct amount. I guess the tab is not really a tab in this case since text may move left or right.
Edit Toolbar
One of the toolbars that is not automatically displayed is called "edit". There are two pairs of buttons on this toolbar that are useful to adjust the indent of the code. They are the ones with the orange boxes and blue arrows. If a block of text is selected they will move the code either right or left 1 level of indentation or just 1 space at a time (for fine tuning). There are many times when blocks of code must slide right or left and this is a great way to do it. Turn on this toolbar using View -> Toolbars -> Edit and give it a try.
Sunday, September 10, 2006
Open Toolbar
One of my favorite toolbars in InnerLoop is not even visible by default. It's called the "Open" toolbar. It's a directory and file browser that is a great help when working in InnerLoop. There are times when I'm working on a project and I would like to open files such as log files that are not part of the project. It seems inconvenient to me to use the File -> Open menu or even the icon of the folder at the top to open them because InnerLoop always seems to start the directory navigation from the wrong place. In fact, I'm not sure how it figures out where to start the directory navigation from (this is a good topic for the future). Many times it seems to be a place related to a different project I had previously loaded. Sometimes it seems to be related to where I store my project and workspace files (which may be nowhere near the actual files used in the project). Using the Open toolbar I can control the working directory that InnerLoop uses for many other commands and also have quick access to open files. I can also see the files in the directory structure without going to the Build tab and using it like a shell to type ls commands.
Enable the Open toolbar and give it a try. By default it will appear on the left side of the screen near the Project toolbar and the top part of the pane will be the files and bottom part is the directory tree.
One of my favorite toolbars in InnerLoop is not even visible by default. It's called the "Open" toolbar. It's a directory and file browser that is a great help when working in InnerLoop. There are times when I'm working on a project and I would like to open files such as log files that are not part of the project. It seems inconvenient to me to use the File -> Open menu or even the icon of the folder at the top to open them because InnerLoop always seems to start the directory navigation from the wrong place. In fact, I'm not sure how it figures out where to start the directory navigation from (this is a good topic for the future). Many times it seems to be a place related to a different project I had previously loaded. Sometimes it seems to be related to where I store my project and workspace files (which may be nowhere near the actual files used in the project). Using the Open toolbar I can control the working directory that InnerLoop uses for many other commands and also have quick access to open files. I can also see the files in the directory structure without going to the Build tab and using it like a shell to type ls commands.
Enable the Open toolbar and give it a try. By default it will appear on the left side of the screen near the Project toolbar and the top part of the pane will be the files and bottom part is the directory tree.
Thursday, September 07, 2006
Bookmarks
We discussed in the past how InnerLoop can navigate code by going to definitions and references for symbols. During this navigation InnerLoop keeps a stack of bookmarks and you can pop back out of the bookmark stack using ctrl-, There are also green arrow buttons on the toolbar at the top of InnerLoop to navigate up and down this stack of bookmarks. This makes it very easy to move around the code.
There are actually 2 kinds of bookmarks in InnerLoop. The 2nd kind is the ability to place a bookmark manually and return to it at any time. This is handy when there is a place you know you will need to keep referring back to and it's not easy to remember where it is.
To access this type of bookmark use the Search -> Bookmark menu item. Type in a bookmark name and hit Add to add this bookmark. You will see a little green arrow in source code indicating a bookmark.
To get back to a saved bookmark use Search -> Bookmark again and select the bookmark you want to return to and hit the Go To button and you are there. You can also use the Replace button to move bookmarks to a new location in the code.
These bookmarks are yet another way to provide easy and time saving navigation in the code. Give it a try.
We discussed in the past how InnerLoop can navigate code by going to definitions and references for symbols. During this navigation InnerLoop keeps a stack of bookmarks and you can pop back out of the bookmark stack using ctrl-, There are also green arrow buttons on the toolbar at the top of InnerLoop to navigate up and down this stack of bookmarks. This makes it very easy to move around the code.
There are actually 2 kinds of bookmarks in InnerLoop. The 2nd kind is the ability to place a bookmark manually and return to it at any time. This is handy when there is a place you know you will need to keep referring back to and it's not easy to remember where it is.
To access this type of bookmark use the Search -> Bookmark menu item. Type in a bookmark name and hit Add to add this bookmark. You will see a little green arrow in source code indicating a bookmark.
To get back to a saved bookmark use Search -> Bookmark again and select the bookmark you want to return to and hit the Go To button and you are there. You can also use the Replace button to move bookmarks to a new location in the code.
These bookmarks are yet another way to provide easy and time saving navigation in the code. Give it a try.
Saturday, August 26, 2006
Installation of InnerLoop
One of the things I like best about InnerLoop is how fast and easy it can be installed.
The download is pretty big, but not as large as installing Specman or NCsim. I can download a new version of InnerLoop and install it in less than 7 minutes. Because InnerLoop doesn't depend on the version of Linux or the version of Java it's never any problem regardless of the type of machine I try to use.
Just extract the tar file and run the script named install.
When the legal verbage comes out as a more just hit q and type yes and enter the directory to install and it's done, that's it.
No configurator to run and no more funny questions.
I would guess Windows installation is different but I have never used InnerLoop on windows, hopefully it's just as easy.
There's something to be said for speed and simplicity when it comes to InnerLoop.
One of the things I like best about InnerLoop is how fast and easy it can be installed.
The download is pretty big, but not as large as installing Specman or NCsim. I can download a new version of InnerLoop and install it in less than 7 minutes. Because InnerLoop doesn't depend on the version of Linux or the version of Java it's never any problem regardless of the type of machine I try to use.
Just extract the tar file and run the script named install.
When the legal verbage comes out as a more just hit q and type yes and enter the directory to install and it's done, that's it.
No configurator to run and no more funny questions.
I would guess Windows installation is different but I have never used InnerLoop on windows, hopefully it's just as easy.
There's something to be said for speed and simplicity when it comes to InnerLoop.
Wednesday, August 16, 2006
Screenshots
Somebody asked me why I don't publish screenshots of all the cool features I describe in this blog.
There are two reasons:
1. It takes too long and I don't have time.
2. If I show the details you won't have to do it yourself to see it. The fun is in learning, trying things and seeing what happens.
Somebody asked me why I don't publish screenshots of all the cool features I describe in this blog.
There are two reasons:
1. It takes too long and I don't have time.
2. If I show the details you won't have to do it yourself to see it. The fun is in learning, trying things and seeing what happens.
Coding Without Errors
After entering a bunch of new code it's usually good to see if it will compile to get rid of all the syntax errors. Last time I discussed using statement templates to avoid typos in the code. This process of edit, compile, edit, compile is part of the reason InnerLoop got it's name. Engineers spend all of their time traveling the inner loop of edit, compile, run, and debug (that is all of their time they are not sending e-mail, surfing the web to read the news, or sitting in meetings).
Another way to cut down the number of iterations is to avoid entering any syntax errors. Of course, it's not so easy. Sure, you could spend more time to inspect the code and hope you can see more of the errors, but that just ends up taking more time.
InnerLoop offers an "Errors" tab that dynamically parses the e code as it is entered. If the parser detects any syntax errors they will show up in the Errors tab. Before even trying to compile anything it's very easy to check the Errors tab and have a look for syntax errors. The parser can't catch every error (yet), but over time I bet it will catch most of them.
Give it a try. See if you can enter new code that is syntax error free (without staring at it for hours) by looking at the Errors tab. It's pretty cool, and I bet vim can't do that.
After entering a bunch of new code it's usually good to see if it will compile to get rid of all the syntax errors. Last time I discussed using statement templates to avoid typos in the code. This process of edit, compile, edit, compile is part of the reason InnerLoop got it's name. Engineers spend all of their time traveling the inner loop of edit, compile, run, and debug (that is all of their time they are not sending e-mail, surfing the web to read the news, or sitting in meetings).
Another way to cut down the number of iterations is to avoid entering any syntax errors. Of course, it's not so easy. Sure, you could spend more time to inspect the code and hope you can see more of the errors, but that just ends up taking more time.
InnerLoop offers an "Errors" tab that dynamically parses the e code as it is entered. If the parser detects any syntax errors they will show up in the Errors tab. Before even trying to compile anything it's very easy to check the Errors tab and have a look for syntax errors. The parser can't catch every error (yet), but over time I bet it will catch most of them.
Give it a try. See if you can enter new code that is syntax error free (without staring at it for hours) by looking at the Errors tab. It's pretty cool, and I bet vim can't do that.
Saturday, August 12, 2006
Statement Templates
I have been working with e for some time, but since my background is much heavier in C and Verilog I still have brain blocks when coding in 3-4 languages every day. At such times I turn to the Statement menu in InnerLoop. The statements menu has templates for all of the common e statements with very easy entry boxes to type in the required names to fill in the template and lay in down in the code. This saves a lot of thinking and looking for similar code to do cut-and-paste when I can't remember the exact syntax of e. It also makes sure I don't end up with syntax errors when I go to compile.
Do you ever try to compile and get a syntax error? Unfortunately, I still do also, but I'm on the way to completely eliminating all syntax errors before compiling with InnerLoop. Next time I'll show you how.
Make sure to check out the Statements menu and request support for additional entries you think are useful.
I have been working with e for some time, but since my background is much heavier in C and Verilog I still have brain blocks when coding in 3-4 languages every day. At such times I turn to the Statement menu in InnerLoop. The statements menu has templates for all of the common e statements with very easy entry boxes to type in the required names to fill in the template and lay in down in the code. This saves a lot of thinking and looking for similar code to do cut-and-paste when I can't remember the exact syntax of e. It also makes sure I don't end up with syntax errors when I go to compile.
Do you ever try to compile and get a syntax error? Unfortunately, I still do also, but I'm on the way to completely eliminating all syntax errors before compiling with InnerLoop. Next time I'll show you how.
Make sure to check out the Statements menu and request support for additional entries you think are useful.
Sunday, August 06, 2006
InnerLoop as a Shell
One of the cool things about InnerLoop is you can do almost everything without ever leaving. To do most anything in Linux requires some typing at the shell prompt. InnerLoop has a very easy way to do it. Highlight the Build tab on the bottom of the tool. Initially, there is nothing there and if you don't use the Build options it may not have occurred to you that this is a shell. To try it out type any command in the box, for example pwd. You will get a nice shell prompt that you can use without having to leave InnerLoop and search for an xterm.
For me, I don't normally use the build system that is provided by InnerLoop. Unfortunately, not everybody I work with is enlightened enough to use InnerLoop and scripts and Makefiles tend to be the way things go. However, this doesn't stop me from using the Build window as a shell. When I want to check my e code and generate a stubs file to make sure life is good, I go to the Build window and type the script or make target to do this. If I have any errors (a rare situation) I can click on them and go directly to the source code and fix them.
I notice some users of InnerLoop have a "never leave" philosophy and other tend to leave when it's time to compile and run. The beauty is that it works either way and any way in between. I tend to spent lots of time in InnerLoop and stay in all the way until I'm ready to simulate and then I leave and go for specify or an xterm to run simulation.
Give the Build window a try as a shell today and see you how you like it.
One of the cool things about InnerLoop is you can do almost everything without ever leaving. To do most anything in Linux requires some typing at the shell prompt. InnerLoop has a very easy way to do it. Highlight the Build tab on the bottom of the tool. Initially, there is nothing there and if you don't use the Build options it may not have occurred to you that this is a shell. To try it out type any command in the box, for example pwd. You will get a nice shell prompt that you can use without having to leave InnerLoop and search for an xterm.
For me, I don't normally use the build system that is provided by InnerLoop. Unfortunately, not everybody I work with is enlightened enough to use InnerLoop and scripts and Makefiles tend to be the way things go. However, this doesn't stop me from using the Build window as a shell. When I want to check my e code and generate a stubs file to make sure life is good, I go to the Build window and type the script or make target to do this. If I have any errors (a rare situation) I can click on them and go directly to the source code and fix them.
I notice some users of InnerLoop have a "never leave" philosophy and other tend to leave when it's time to compile and run. The beauty is that it works either way and any way in between. I tend to spent lots of time in InnerLoop and stay in all the way until I'm ready to simulate and then I leave and go for specify or an xterm to run simulation.
Give the Build window a try as a shell today and see you how you like it.
Sunday, July 30, 2006
Comprehending Source Code
In my last entry I explained how to find out exactly which files are part of an environment. Once you have the right set of files identified and loaded into an editor, the next logical thing is to be able to navigate the source code and find all the relationships in the code.
As you probably know e uses Aspect Oriented Programming (AOP). There are a lot of theoretical explanations of AOP, but suffice it to say it means that data structures can be "extended" to add more fields and methods from anywhere. This extend concept leads to 2 challenges. First, it's hard to find all of the extenstions and get a complete view of the fields and methods in a struct or unit. Second, it means nobody every edits any source files for fear somebody else is using them the way they are so they just make a new file and add some extends. This leads to many files to manage. It's actually a good thing as long as you have InnerLoop as the tool to handle the navigation. If you have emacs or vi them AOP makes your life miserable.
The most important shortcuts to remember are:
ctrl-. to go to the definition of an item
ctrl-/ to get all the references for an item
ctrl-, to pop back from a definition to the original location.
These 3 key strokes will save 95% of the searching and grepping engineers do so it makes sense to master them. These are especially useful if you need to work with other people's code or code from an eVC that you did not write.
Please don't try to write a perl script or create some tool that tries to make HTML links for all the extends, it's not worth your time, just get InnerLoop.
InnerLoop has other interesting features to set bookmarks and move to them so you can save markers in important places, but that's a topic for another day.
In my last entry I explained how to find out exactly which files are part of an environment. Once you have the right set of files identified and loaded into an editor, the next logical thing is to be able to navigate the source code and find all the relationships in the code.
As you probably know e uses Aspect Oriented Programming (AOP). There are a lot of theoretical explanations of AOP, but suffice it to say it means that data structures can be "extended" to add more fields and methods from anywhere. This extend concept leads to 2 challenges. First, it's hard to find all of the extenstions and get a complete view of the fields and methods in a struct or unit. Second, it means nobody every edits any source files for fear somebody else is using them the way they are so they just make a new file and add some extends. This leads to many files to manage. It's actually a good thing as long as you have InnerLoop as the tool to handle the navigation. If you have emacs or vi them AOP makes your life miserable.
The most important shortcuts to remember are:
ctrl-. to go to the definition of an item
ctrl-/ to get all the references for an item
ctrl-, to pop back from a definition to the original location.
These 3 key strokes will save 95% of the searching and grepping engineers do so it makes sense to master them. These are especially useful if you need to work with other people's code or code from an eVC that you did not write.
Please don't try to write a perl script or create some tool that tries to make HTML links for all the extends, it's not worth your time, just get InnerLoop.
InnerLoop has other interesting features to set bookmarks and move to them so you can save markers in important places, but that's a topic for another day.
Tuesday, July 18, 2006
Can you find all your e files?
One of the biggest challenges with Specman environments is finding all of the e files that get loaded. Sure, you can open specview when they are all loaded and File->Modules but then what? It's not like you can output some list that your editor uses to load the files.
Using specview to view and open a new editor every time you click on a file is a terrible way to develop software. Not only because it uses an expensive Specman license, but it very inefficient. The modules view is good for setting breakpoints in the code, but not development.
The best way to find all the e files and get them into an editor is the InnerLoop e Project Wizard.
When you create a new project choose
e: New Project Wizard
On the 2nd form select
Create new project from existing top-level file.
Hit the button with ... and browse for a top-level .e file and InnerLoop automatically finds all the files that would be loaded into Specman in the same way Specman does, using the SPECMAN_PATH environment variable. Now you know all the files in the project and can effectively do software development.
What if the list of files in the project gets stale?
Some people may have figured out how to use the wizard to get the files into InnerLoop autmatically, but what if you remove files or add files to the project? You can add and remove files manually by right clicking in the projects toolbar, but it's not necessary.
There is a command that will replicate just what the wizzard did. When I get a stale set of files, I sometimes just remove all the .e files from the project and run the command with my top-level file as the argument:
syncprojfiles test1.e
and InnerLoop puts back the current list of files in the project, very nice.
To run syncprojfiles (or any other command) click on the bottom of the InnerLoop window and you get a white box to enter commands.
In the next intallment I'll show you how to find things without doing:
% find . -name \*.e | xargs grep findme
One of the biggest challenges with Specman environments is finding all of the e files that get loaded. Sure, you can open specview when they are all loaded and File->Modules but then what? It's not like you can output some list that your editor uses to load the files.
Using specview to view and open a new editor every time you click on a file is a terrible way to develop software. Not only because it uses an expensive Specman license, but it very inefficient. The modules view is good for setting breakpoints in the code, but not development.
The best way to find all the e files and get them into an editor is the InnerLoop e Project Wizard.
When you create a new project choose
e: New Project Wizard
On the 2nd form select
Create new project from existing top-level file.
Hit the button with ... and browse for a top-level .e file and InnerLoop automatically finds all the files that would be loaded into Specman in the same way Specman does, using the SPECMAN_PATH environment variable. Now you know all the files in the project and can effectively do software development.
What if the list of files in the project gets stale?
Some people may have figured out how to use the wizard to get the files into InnerLoop autmatically, but what if you remove files or add files to the project? You can add and remove files manually by right clicking in the projects toolbar, but it's not necessary.
There is a command that will replicate just what the wizzard did. When I get a stale set of files, I sometimes just remove all the .e files from the project and run the command with my top-level file as the argument:
syncprojfiles test1.e
and InnerLoop puts back the current list of files in the project, very nice.
To run syncprojfiles (or any other command) click on the bottom of the InnerLoop window and you get a white box to enter commands.
In the next intallment I'll show you how to find things without doing:
% find . -name \*.e | xargs grep findme
Wednesday, July 12, 2006
The Need for a Developement Environment
I'm still amazed at the primitive text entry tools engineers use to do design and verification on complex SoC projects. It was clear about 7 years ago engineers want to keep text entry as the way they enter design and verification code when attempts at graphical design entry failed.
I agree that text is the right way to go, but engineers spend more time with an editor than any other program (including e-mail and web browser) so they should at least have a tool with some good features to navigate the code.
Still in 2006, most engineers are using tools that are 30 years old, things like vi and emacs to try to create and maintain projects with a large number of files.
In his column at embedded.com, Jack Ganssle wrote some interesting thoughts about advancing the state of the tools that process the text files to bring them up to the 21st century. I doubt anything will change, but it makes you think.
http://www.embedded.com/showArticle.jhtml?articleID=179101955
It's true we live in a hyperlinked world and working with code should be just as easy as navigating the web. When I see engineers doing
% find . -name \*.v -print | xargs grep my_module
it's extremely depressing.
I'm still amazed at the primitive text entry tools engineers use to do design and verification on complex SoC projects. It was clear about 7 years ago engineers want to keep text entry as the way they enter design and verification code when attempts at graphical design entry failed.
I agree that text is the right way to go, but engineers spend more time with an editor than any other program (including e-mail and web browser) so they should at least have a tool with some good features to navigate the code.
Still in 2006, most engineers are using tools that are 30 years old, things like vi and emacs to try to create and maintain projects with a large number of files.
In his column at embedded.com, Jack Ganssle wrote some interesting thoughts about advancing the state of the tools that process the text files to bring them up to the 21st century. I doubt anything will change, but it makes you think.
http://www.embedded.com/showArticle.jhtml?articleID=179101955
It's true we live in a hyperlinked world and working with code should be just as easy as navigating the web. When I see engineers doing
% find . -name \*.v -print | xargs grep my_module
it's extremely depressing.
Monday, July 10, 2006
What's in a name?
A lot of people ask how the company got its name. When Dave Von Bank, the President of the company, had the idea to start a software company he asked if I knew any good names. Since it would probably be an EDA company I tried to think of something related to design or verification. I didn't want to suggest some kornball word blend like Xpediate that nobody would ever pronounce correctly. The two simulation things that came to mind were TimeZero and Posedge. TimeZero was pretty cool since it's a term everybody uses when talking about what is happening in a simulation, but unfortunately it communicates a company that is stuck in the starting gate with no forward progress. Posedge is a term typed over and over again by Verilog coders to represent the rising edge of a signal, normally a clock. I liked the notion of a positive edge of the clock, it's up and to the right, a good trend for a company and communicated a positive momentum, and it stuck.
When this name was chosen I thought for sure nobody could botch the pronounciation of it, but amzaingly enough a lot of people still do.
The other drawback of the name is the domain name was not availble so it became
posedgesoft.com but I guess not everyhing can be perfect.
A lot of people ask how the company got its name. When Dave Von Bank, the President of the company, had the idea to start a software company he asked if I knew any good names. Since it would probably be an EDA company I tried to think of something related to design or verification. I didn't want to suggest some kornball word blend like Xpediate that nobody would ever pronounce correctly. The two simulation things that came to mind were TimeZero and Posedge. TimeZero was pretty cool since it's a term everybody uses when talking about what is happening in a simulation, but unfortunately it communicates a company that is stuck in the starting gate with no forward progress. Posedge is a term typed over and over again by Verilog coders to represent the rising edge of a signal, normally a clock. I liked the notion of a positive edge of the clock, it's up and to the right, a good trend for a company and communicated a positive momentum, and it stuck.
When this name was chosen I thought for sure nobody could botch the pronounciation of it, but amzaingly enough a lot of people still do.
The other drawback of the name is the domain name was not availble so it became
posedgesoft.com but I guess not everyhing can be perfect.
Thursday, June 29, 2006
Welcome to the world's first blog on InnerLoop, the software development tool for design and verification engineers.
This is the place to learn about all the cool stuff that can be done with InnerLoop.
Visit www.posedgesoft.com for details on how to get it!
Why do this as a blog?
I found that nobody reads User Guides, Help, FAQs, or any other proper documentation and besides these things are usually boring. The blog format is easy to read and has no requirement to be comprehensive so just the cool stuff can be shown. It also promotes discussion.
This is the place to learn about all the cool stuff that can be done with InnerLoop.
Visit www.posedgesoft.com for details on how to get it!
Why do this as a blog?
I found that nobody reads User Guides, Help, FAQs, or any other proper documentation and besides these things are usually boring. The blog format is easy to read and has no requirement to be comprehensive so just the cool stuff can be shown. It also promotes discussion.
