Mark's View

Moved from main page.

How I see this working.....

1/ a user asks an EDA tool to present some information about an IP block for some specific period of time (maybe all time) 2/ The EDA tool uses some Analysis IP to analyse raw data and produce data that the tool will present to the user 3/ The Analysis IP asks the timing controller to enable the raw data to be generated for the time periods required 4/ The IP block has a simple API inside, somehow magic is performed to make this costless when nobody is interested in the raw data, the timing controller switches this on and off.

BUT:

The Timing Controller COULD provide some rudimentary timing related processing and data collection:

    The Analysis IP would then have a simple interface to the Timing Controller asking it to collect data over given time slots, and when the data was collected to call back to the Analysis IP (using a port/export as per normal GreenBus,  passing the collected data as a pointer, as per normal).

I think the timing controller was what you were calling the GAV_plugin?It should have a "config" interface on it that allows timing scenarios to be set up and run, and data collected - either allowing the data itself to pass via SCV, or being collected by the Timing Controller and passed back to the Analysis IP. This object should be fairly simple. I dont think there is much the timing controller can do except collect data over time. Hey - lets go the whole way and say it can have an unbounded array of off and on times... thats about it!

Note - If SCV is being used, I am not sure, but maybe there is no need for the timing controller to "control" the IP block, it simply registers, and removes itself from the SCV streams???? If this isn't possible, then my preferred solution doesn't work - in which case, I'm not sure of the value of SCV at all? (Except to feed out to tools that need it?)

Note for a horses mouth, SCV is not the right tool for this, we should be looking at an analysis port - such that you either bind to it or not - but then, we need dynamic binding....

So - finally, here is my preferred solution:

We provide a library of nice easy to use magic blocks that use SCV We provide a timing controller, which has a GreenBus API, which can be EASILY connected to any tool API we can find. We provide example Analysis IP and show it working in (say) eclipse. We show this connected up to a/n/other tool API.

• If the tool uses the SCV feed directly, then it bypasses our stuff,
• if the tool uses SCV but has no timing controller, our stuff can be used to do the timing controlling, and then feed an scv into the tool.
• if the tool has it's own API we should be able to support it via the GreenBus approach....

All we need to build is an example of a piece of analysis IP, and show the whole thing working. The point being that then somebody should be able to write Analysis IP (hopefully easily, and re-usably), outside of a tool context. It's going to be down to people like them to convince tool vendors to provide the "internal" interface such that this IP can connect into a tool vendors environment. Meanwhile, we can show it all working within an eclipse environment. It _MAY_ be that The Interface ends up being the use of Eclipse as a framework to interact with the user.

what is the situation today? Something like this:

The tool vendors provide a tool that has everything including some of the timing controller in it, and they provide libraries that IP writers should use so that they can connect their IP back to the tool.

Our job is to provide them with a place to add value. In many cases, their value is in the analysis IP - and it's tight integration (including the library they supply IP writers)...

The issue is supporting this "efficient and highly tuned" API in a vendor neutral way and not loosing performance.

And the other problem:

I think the key is that the person supplying Analysis IP _MAY_ be a tool vendor (their value), or _MAY_ be the IP vendor (IP specific anaysis) or _MAY_ be a third party (open market in Analysis IP), or the System Integrator (System specific analysis)!

So, Tools need to have an "Analysis IP" independent way of connecting to Analysis IP. I suspect that is the problem. THE value in a tool will be the analysis it can perform, and the ability to provide that analysis to an end user.