Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won

  1. Hi Richard, Could you kindly explain how one could participate in the IP-XACT committee? Is it possible for non accellera members to contribute? Thanks, Chris
  2. Hi Uwe, Thanks for the response. I agree, if the reference implementation is not part of the standard then this is less significant. However I maintain that it should be possible, and not particularly difficult, to write a standards compliant implementation with conditional compilation for DPI, VPI, VHPI, SystemC interfaces depending on whether they are available. I doubt this would in practice be any slower than the current implementation. There is a "reasonable path" to achieving this, the obstacles are purely the incentives and lack of oversight. The vendors have little incentive to put in the effort to write standards compliant code, having been allowed to split out into separate proprietary files leaving no motivation to maintain cross-compatibility. The oversight and sufficient review process hasn't been in place to keep the vendors in line. The fact that the vendors aren't able to write cross-simulator standards compliant code is nothing less than a damning failure of both the standards committees and the vendors! However I would see this as a rallying call to the vendors - a challenge if you will - to rectify this situation and prove me wrong, regardless of the IEEE standardisation effort. Thanks, Chris
  3. Do you think there's any possibility of hosting the UVM repository on a more modern platform? For example, hosting the code on Github rather than Sourceforge would allow contributors to submit patches for review and generally encourage wider participation in the development process.
  4. Hi Uwe, Thanks for the response. I appreciate that it's not an ideal world, however you are effectively saying that it's too difficult to achieve a reference implementation using the existing standards and I strongly disagree with this. It might not be possible to provide an implementation that is optimal for all vendors, however that is not the purpose of the reference implementation. Many vendors bundle a UVM implementation with their simulators so if they want to optimise to differentiate, that is the appropriate place to do so. If they have failed to implement the required standards then their workarounds should go there. By all means allow vendors to optimise, but that doesn't belong in the reference implementation. The reference implementation shouldn't rely on any non-standard vendor specific implementation details. This should definitely be feasible! As you note - it's possible to do a part select with VPI using a bit-by-bit access (vpi_handle_by_index or vpi_handle_by_multi_index). It's also possible with DPI. I think the problem is that the motivation isn't present right now - it is possible to write cross-simulator compatible VPI code, it just takes a little more effort. By allowing the vendors to duplicate implementations you have removed all motivation to even attempt to stay standards compliant. My biggest issue is really the message this sends - if the vendors themselves are unable to write a relatively simplistic bit of functionality conforming to the standards without resorting to proprietary hacks, what hope do us users have? You also have to appreciate the irony of the situation - a methodology promoting use of standards and re-use is unable to be implemented using the existing standards and contains copious amounts of copy'n'pasted code! If putting the reference implementation forward as part of the IEEE standard then this needs to be addressed. I believe with the right incentives and processes in place it will be possible to create a generic reference implementation. I also think that the vendors should work together to create a generic this as a display of confidence in existing IEEE standards and the quality of their own products. If they are unwilling, my offer to assist in this effort with patches still stands. To answer your specific points: I think you've been successful with SV because that is the main strength of your contributors. With proper development and review process this wouldn't be so hard to maintain and it should be possible to enforce a consistent standard of code. I disagree - the feature-set of UVM should be consistent and only use standards. The only conditional compilation in the C codebase would be selecting which standards are available. To clarify, the granularity is whether a standard is available (i.e. DPI, VHPI), not to particular vendor tool/version capabilities. Thanks, Chris
  5. The C code under src/dpi has various issues which should be improved if the reference implementation forms part of the standard. Duplicate code There is significant duplication of code in the uvm_hdl_*.c files (almost 50% duplicate code). This is clearly below the quality one would expect from an industry standard. Since the interface to the simulators use IEEE standards (VPI, DPI and VHPI) it should be possible to have a single implementation that works on any standards compliant simulator. If simulator specific workarounds are required they should be minimised. Inconsistent Features The features provided by the different implementations are not consistent. For example, VCS doesn't provide a part-select, and Questa doesn't support VHPI. The part-select capability is a useful feature and possible using standards compliant calls. Overall, rather than splitting out (and duplicating) this code into separate files for different simulators, there should be a single reference implementation. Features that depend on standards should be conditionally compiled based on the interfaces available, not the simulator itself (for example #ifdef VHPI_AVAILABLE rather than #ifdef VCSMX). Any simulator specific workarounds should be avoided if possible, with the aim of eliminating them completely. There are also various style/best practice issues with the C code - for example including a .cc inside an extern "c" block (as mentioned previously). I'm happy to contribute patches to assist with any improvements. Thanks, Chris
  6. Further comments on the code in distrib/src/dpi: 1. The splitting of vendor implementations for uvm_hdl into separate files is a step backwards. There is now no default implementation, and no attempt at all to keep a common code-base or feature set. Since PLI is a long established standard, there shouldn't be much need for vendor specific tweaks, and those that are should be minimal enough to be handled with #ifdefs in the single file. There's now much duplication, which is bad. Long term the goal should be to minimise the vendor specific hacks and converge on one universal implementation. Splitting out the files into vendor does makes this unachievable. 2. Part-select in path names should be universally supported using vpi_handle_by_name. See this question on StackOverflow: http://stackoverflow.com/questions/24212081/how-do-you-define-backdoor-access-for-fields-which-span-two-registers And finally a meta-comment, is there ever going to be any feedback on the feedback? Is anybody reading this?! Thanks, Chris
  7. I have a register map along the following lines: -----------------------+-----------------+--------------------------------- Byte offset | Register Name | Description -----------------------+-----------------+--------------------------------- 0x00 | width | Width (in bits) of structure 0x04 | height | Number of rows 0x08 | offset | Offset of the structures ********** Variable sized gap ********** $offset | Item 1 | First structure $offset + 4 | Item 2 | Second structure $offset + 4 * N | Item N | Nth structure $offset + $height *N | Last item | Final structure The software will read the width, height and offset registers and run-time and use these to determine the layout of the dynamic part of the component address space. As far as I can see from the IP-XACT specification, there's no way to describe a dynamic register layout (or unknown until run-time). Does anybody have a suggestion for how to achieve this is the cleanest way? Thanks, Chris
  8. According to this paper it should be possible to wrap SystemC using SWIG: http://glibersat.linux62.org/~glibersat/CSD13_final.pdf
  9. There are some issues with the following file: code/distrib/src/dpi/uvm_dpi.cc It includes a .cc file inside an extern "C" { block which is misleading It includes everything into a single file which is not generally considered best practice for software development since it will pollute the namespace It breaks a build systems ability to correctly determine dependencies I recommend that this file should be removed from the distribution since it is superfluous and problematic for the reasons described above. The only possible advantage of this mechanism would be a slight speed increase due to reduced file IO, however for such a small amount of code this is negligible.
  • Create New...