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.
