Hi Per, Please see my notes below. Thanks, Shabtay >-----Original Message----- >From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per Bojsen >One possible implementation is to layer it on top of SCE-MI 1.1. There >are three cases: > >1) Imported function calls. Replace each imported function call with >an input port, output port, and a clock control macro. Map all input >arguments to the message of the output port. Map all output arguments >and the return value to the message of the input port. Stop the clocks >using the clock control macro when an imported function call happens. >Send the output message to the software side and wait for the input >message. The input message carries the return values and the output >arguments. When the input message arrives, start the clocks again >and continue on. > >2) Exported function calls [zero time by definition since it is >a function]: Use an input port to carry input arguments to the >exported function and to indicate when the function should be >invoked. Stop the clock using a clock control macro when the >input message arrives. At the end of the call, send the output >arguments and any return value to the software side using an >output message and start the clocks. > >3) Exported tasks [may be non-zero time]: This is an extension of >(2) but is a little more tricky as the clocks need to be allowed >to run during the execution of the task. Now, only stop the clock >while communicating with the input and output ports, that is, stop >the clocks while waiting for the dual ready handshake to complete. > >Since the above is based on SCE-MI 1.1, it is trivially backwards >compatible with SCE-MI 1.1. [Shabtay] Your proposal is based on using clock control SCE-MI 1.1 in simulation. Such an implementation now forces us back into viewing time progression on the HW side by only using cycle stamps. This imposes significant restrictions on the user. Simulators don't stop accounting for time when cclocks are stopped and uclock continues running. Any trace data and any system tasks that uses time will see a different time from the one reported by cycle stamp. Practically, the simulation use model will be highly restrictive. Neither the macro based approach across all HDLs that Cadence proposed in the past nor the existing DPI based proposal for SystemVerilog imposes such a restriction on the end user. Why would we impose it only on Verilog and VHDL users? > >The infrastructure linker analyzes the HDL source and finds all >the imported and exported calls and can do the work to insert >the appropriate infrastructure as described above. > >> Item 2 - No code regeneration - Each API dictates the methodology by >> which the models (transactor) need to connect to the interface >> (function-based or macro-based). You are telling me that I need to >> emit new code in SCE-MI 1.0 (or macro based approach for Verilog and >> VHDL). Please explain why? To my knowledge, once I have created set of >> files that connect to SCE-MI macros, I can link in other files that >> which constitute the "guts" (by instantiation) w/o touching the >> original files. Is this correct or not? If not, why not? > >This is not correct because the macro interfaces as defined in SCE-MI >1.1 are missing the infrastructure connections required to implement >items such as uclock and ureset. This is especially a problem in VHDL. >Also, somewhere you need to add the global clock generation and reset >infrastructure. For instance, all the ready for clock signals must >be considered at once to determine when to stop and start the cclocks. >Show me how to add this infrastructure without emitting some code and >without modifying some of the user's code. [Shabtay] We need to distinguish between modifying user's source code and mandating that users comply with a certain methodology. Independent of the API that is being used, users will have to build transactors, define the hierarchies and make connections to certain API resources in a certain way. Everything that you have described so far falls into the methodology of using the SCE-MI 1.1 API and none requires regeneration of the user's environment. Different implementation can do different things. The macros "guts" for example could be fully generated by the infrastructure linker or a parameterized library may be linked in. This is not considered regeneration of the user's code as the code that the user has generated is not modified. The user's code works with a well defined interface with known semantics where the implementation of the modules representing the interface could change or be regenerated, but not the user's code. > >There are a few key points that we seem to be stumbling on here: > >1) Shabtay's no code regeneration requirement. So far I have not heard >a compelling argument for why this should be a requirement. [Shabtay] The strongest reservation I have to modifying users' code is the implication on debug. Users who understand the interface requirements and semantics can debug their code in the context of a given interface. It is not acceptable to modify their code (even if we state that the modified code is equivalent) and ask users to debug a modified code regenerated by our application. Do you still think that this is acceptable to simulation users? The only >semi-compelling argument I've heard so far is that users might be >inconvenienced by having to run the infrastructure linker before >compiling their source code, and if the infrastructure linker is >implemented using something like VPI, they'd of course have to compile >their code twice. However, that can easily be remedied by writing >a simple wrapper script around the simulator that takes care of those >details. > >2) The function based approach requires code regeneration, but the >macro based does not. While I think I agree with Shabtay that some >degree of source code regeneration/pre-processing is required for the >function based approach, I do not agree that it is not required for >the macro based approach. [Shabtay] We have already at Cadence several implementations of SCE-MI 1.1 and the macros we proposed that do not require user's code regeneration on various simulators (if you agree with me that API use model requirements don't constitute code regeneration). > >Shabtay, is your opposition to the function based approach solely >based on the opposition to code regeneration? If not, could you please >list what other reasons you have for opposing the function based >approach in VHDL and regular Verilog? For VHDL, I guess one other point >is that what we would be standardizing on would be an interface that >is surely different from any DPI-like interface that might be added to >VHDL in the future. But on the other hand, I do not think we can wait >for the VHDL committee to add something like that. I think it would >be quite useful to have an interim solution based on the attributes >which we can then deprecate once VHDL-DPI becomes available. I doubt >that will be within the next 5 years, though :-) [Shabtay] We are not opposing to functional-based API for Verilog and VHDL at long as it meets the principles that I have outlined. But I have not seen yet a proposal for a functional bases API that its implementation meets these principles. Now, it is my understanding that you also support Russ idea to focus on SystemVerilog for SCE-MI 2.0 and deal with Verilog and VHDL for SCE-MI 2.1. Should we then stop discussing this at this point and focus on SystemVerilog for SCE-MI 2.0? > >Thanks, >Per >Received on Tue Oct 11 15:16:49 2005
This archive was generated by hypermail 2.1.8 : Tue Oct 11 2005 - 15:16:58 PDT