( ESNUG 452 Item 6 ) --------------------------------------------- [02/17/06]
Subject: Questions for Kathryn Kranen, CEO of Jasper
I'm curious how Jasper is dealing w/ the fact that their Chief Methodologist
Harry Foster abandoned ship and went to Mentor. What damage control is
Kathryn doing?
---- ---- ---- ---- ---- ---- ----
To: Kathryn Kranen - CEO of Jasper
What is the cause of your recent brain drain, how will it affect Jasper, and
how will you recover from it?
---- ---- ---- ---- ---- ---- ----
The obvious question to Katheryn Kranen is what is the future of Jasper
with the founders and Harry Foster gone!
---- ---- ---- ---- ---- ---- ----
To Jasper
What's your burn rate? How soon before you shut the doors?
---- ---- ---- ---- ---- ---- ----
Kathy - Jasper
Jasper has lost 10 sales people in the US in the past 12 months (this is
a startup mind you) and now Harry Foster left. Is it more a reflection
on the tool/technology, or the sales effort? If the tool is ready, why
are sales people leaving? Are they trying to move the tool too fast?
Equivalence checking was a big hit for us, but all other formal tools
have gone down the drain.
---- ---- ---- ---- ---- ---- ----
Kathryn - Will design engineers ever embrace writing assertions? Is that
why Jasper can't get any traction? If that's not the problem, what is?
---- ---- ---- ---- ---- ---- ----
This is somewhat pointed at Synopsys, but to Katheryn at Jasper - We've
evaluated Synopsys Magellan, and love the premise but not necessarily
the current implementation. How far is the industry from having a
hardened formal verification tool that can begin to eliminate the need
for module-level simulation? Verification consumes a large part of our
overall effort, and it would be great if we could concentrate our
manual-labor-intensive simulation energies on problems that exceed the
capacity of Formal tools. We need easier ways to define intent for
packet-based/transactional interfaces (multiple clocks to transfer an
entire "packet" where data/address/otherFields are encoded into
different locations). Not all designs can handle purely random
bit-twiddling on its inputs. We're willing to spend the money on formal
tools only if they're able to do more of the work. If we have to do
tedious work like write BFMs (on top of the concise assertions for the
rest of the design) to turn random bits into proper packets, we might as
well have simply used a verification language and a simulator with
coverage enabled.
Why should I use a flaky formal tool when a verification language and a
simulator from Cadence or Synopsys does the job?
---- ---- ---- ---- ---- ---- ----
I have a question to Kathryn Kranen:
We have seen the move from timing simulations to STA in the physical domain.
Do you see a similar trend in functional verification with static formal
tools completely replacing today's functional simulations in say 5 years?
Or will static formal verification always be limited to the block level?
---- ---- ---- ---- ---- ---- ----
To Kathryn Kranen (Jasper):
Will Jasper's flagship product, JasperGold, support formal verification
of "data transformation" intensive blocks? Currently, "data transport"
type of blocks are considered formal friendly but not "data transformation"
types which are mainly used in DSP based designs. Intel has an in-house
tool that has out-performed JasperGold in an evaluation conducted by Intel
engineers. For the rest of us who don't work at Intel, getting 100%
coverage on DSP blocks is a huge problem.
Index
Next->Item
|
|
