chiggs

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

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

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

According to this paper it should be possible to wrap SystemC using SWIG: http://glibersat.linux62.org/~glibersat/CSD13_final.pdf

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.