Greg Maston
Software and Hardware Solutions Provider
Denver, CO
US (303)748-2584
Software Skills
Languages:
C, C++, Lisp, Tcl/Tk, Python, Perl, HTML, Pascal, Fortran
Coding Environments:
Visual Studio, any IDE, and happiest in Emacs
Code Config Management:
Clearcase, Perforce, Git
Code Development:
Software Lifecycle and Process Maturity Models, Agile
Software Quality Assurance:
Valgrind, Coverity, Gcov, Gprof, Purify, Purecov
Hardware Skills
Languages:
Verilog, VHDL, EDIF
Simulation, Test, and EDA:
Synopsys Design Compiler, TetraMAX, VCS, Cadence NCSim, Verilog-XL, Mentor Fastscan and MTI, Cadence Framework and Skill language
ATE:
HP 82k, 83k, Teradyne A300, Sentry 21, 1650, Schlumberger ISS2k, LTX Trillium
Tool Skills
Documentation/Spreadsheet:
Adobe Framemaker, all Microsoft tools
Platforms:
Linux / UNIX (many flavors), Windows, VAX/VMS, DOS
Work Perspectives
The following discourses identfy some areas of work experience that I consider to be on the more-artistic or philosophical side of the day-by-day work events. The day-by-day events can be found on my linkedin page; the musings below identify the artistry of the engineering world as I've come to experience it.
Hardware/Software Dichotomy
The identification of the hardware components and the software operation driving that hardware is a cornerstone of IC chip/SoC design architecture: how much operation requires hardware support, and what part of the functionality can be supported or implemented by software or software-based interfaces to the hardware? Digital device testing strategies, due to the opportunities for efficient test generation by software tools, are dependent on the presence of hardware constructs to facilitate the test. From the basic scan-based organization of the sequential elements in a design (to support software algorithms centered on controllability and observability metrics), to the continuously evolving hardware compression architectures incorporated to reduce test overhead and test cost, circuitry is added to provide for the test goal of verifying structural (interconnect and logical) and functional (for example, operational-based clocking) behaviors of large multiple-component SoC designs. Hardware requirements have been driven by the limitations of software and organizational time-to-market limitations, at least for component testing.
Software Orientation
Performance, usability, and reliability of technical software tools (in my experience, such as the digital test generation tools on the market) are paramount to customers. And often, large and complex software can be applied in contexts that were unanticipated, resulting in unexpected behaviors (my experience, such as passing hundreds of model libraries with the netlist description, when only one of those libraries is used in a design). When faced with these challanges, root-cause identification of the unexpected behavior is critical on many levels: to leverage learning opportunities for developing robust software, to better define software requirements, and to implement a solution that is integrated with the overall tool. I especially value the review of the software process as part of this maintenance, to improve the software development process overall.
Software Languages Orientation
Software interfaces are often structured as languages or formats for information, to pass data between tools or between tools and people. In this space, the opportunity to manage data complexity is part of the language behavior, and understanding that behavior is required to effectively apply a software language. During my career I have had opportunities to define languages applied to digital simulation (behavioral netlist representations) and for passing large amounts of digital test data (test vectors) between domains of usage. Aspects of the philosphy of the language provide insight into language use; for instance the C language was defined to reflect low-level hardware operations, while Lisp is abstracted away from any hardware details. However, effectively defining and providing the philosophy of use is only one aspect of the issues around language definition. Effectively disseminating that language behavior to the users is even more critical - which opens the door to the need for standards in my workspace, below.
Electrical Engineering Orientation
Working on operations that test digital designs provides constant access to leading-edge electronic technologies and holds the door always open for new solutions that are sufficient to validate operation and that maintain the software requirements of performance, usability, and reliability. The trade-offs between the operational requirements of the hardware and the software opportunities can only be effectively made using domain knowledge from both camps.
Industry Standards Orientation
I participated in an effort initiated by two companies that needed to pass immense sets of test data for digital logic between them, and were bottlenecked by the only available format for this information. This resulted in the creation of a standards group to address the shortcomings of the existing options. Working on a standards project provides for a wider industry perspective on the problems and (by intention) results in a more universally-acceptable standard at the cost of what can be a lot of haggling between perspectives. I value the perspectives I have gained from participating in these efforts, and I value the extended opportunities available to the industry by applying these standards.