[ibis-macro] Re: DLL debugging and validation
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: <essaid.bensoudane@xxxxxx>
- Date: Tue, 31 Jul 2007 17:08:53 -0400
Essaid,
Thanks for your feedback.
We're not trying to mandate any environment for model development, including
the IBIS_AMI_test
program being turned being over to the IBIS Open Forum. A model developer is
free to write, execute
and debug their models in whatever environment they choose - assuming the
debugger can gain access
to the model as you indicate.
The thing we're trying to accomplish with IBIS_AMI_test is to provide access to
an independent,
"golden" reference when model or EDA developers interpret the API spec
differently. That golden
reference shouldn't be under the direct control of any individual company,
which is why we think the
code should ultimately be maintained by the IBIS Open Forum.
From a purely personal standpoint, I think having a standalone executable that
loads and executes
models is a good development/debug vehicle - but there are lots of other ways
to approach the
problem.
As far as licensing IBIS_AMI_test goes, that will be the IBIS Open Forum's
decision. We were simply
suggesting the way the Open Forum licenses IBISCHK as an example that may be
worth following.
Monies from IBISCHK licensing help support different IBIS activities, and since
people don't usually
stand in line to donate money to the EIA, we were simply trying to help where
we could.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Essaid
BENSOUDANE
Sent: Tuesday, July 31, 2007 4:17 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] DLL debugging and validation
Subject: Debugging and validation
A final product for SERDES modeling using the BIRD should allow the
model developer to debug it's own source code under any platform. It's
not true that the only way to debug the Dll is to have access to source
code that load it. The C compiler allows individual file to be compiled
on various mode (see gcc switches). Therefore you could choose to
generate files symbol tables or not.
Adding any license fee for an environment to allow debugging is not
acceptable at all. By default debugging capabilities should be included
in the tools. Tools provider should find a solution to be able to hock
gdb to their tools as a client. I already used similar stuff in the past
to integrate processor C-ISS models (as slave) in some EDA tools and I
was able to debug my code without need to have access to EDA tools
source code.
Having access to both test environment and model for the current
environment is understandable, but it should not be the rule.
Functional validation is another issue, where the model developer should
make sure his model much the desired functionalities. In some cases the
model should be validated to reflect an already existing SERDES. It's
the responsibility of the model developer to make sure the DLL he
delivers is validated and conform to ATM specification.
Best regards,
--
Essaid Bensoudane | System-on-Chip Platform Automation
essaid.bensoudane@xxxxxx | STMicroelectronics, AST
Phone: +1-613-768-9006 | 16 Fitzgerald Road, Suite 300
Fax: +1-613-768-9025 | Nepean, Ontario K2H 8R6 Canada
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
