olofk

Members
  • Content count

    6
  • Joined

  • Last visited

About olofk

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  1. Thanks for the reply. I see your point. Will look into namespacing the classes somehow Thanks, Olof
  2. Hi, I've been looking at creating a Python library to work with IP-XACT. My current attempt (https://github.com/olofk/ipyxact) implements a small subset of IP-XACT, but it would be too much work to do this for the complete standard, so instead I've been looking at using generateDS to help me with the process of creating classes. The problem that appears now is that there are some tags in the schema files with identical names that are defined in several places. An example of this is the viewRef type. It is defined in 7 different places. Some of these are identical, which leaves us with 3 unique definitions. These three unique versions are similar enough so that the python classes are actually identical for all 7 definitions. My question is therefore, should there really only be one definition of viewRef, that all the other can refer to? The same thing would apply to other tags as well, such as accessHandles, registerType, portType etc, or am I missing something? I haven't dealt with xsd files before, so my knowledge of the subject is limited
  3. Ah! That is a much better solution. Hope to see things moving in this direction
  4. @John That's a very good point. I believe we are about to see an explosion of new hardware modelling languages in the coming years, and it will be very hard for IP-Xact to keep up with this. On the other hand, it's nice to have standardized names for the ones that IP-Xact do know about. One solution for this could be to have a sub tag for the user tag that allows setting a custom name. This could serve as a staging area for coming revisions.
  5. Hi, I looked at the file types in IEEE 1685-2014 and noticed that there are neither a vhdlSource-2008, nor a verilogSource-2005. Both would be useful to distinguish version-specific features such as $clog2 for vlog2005 and all the new stuff in VHDL 2008. Are there any plans to add this to an upcoming revision?
  6. Hi, I finally started to explore IP-XACT with the intention of creating bus definitions and interface models for most of the cores we use in the OpenRISC ecosystem. During my brief encounter I have come across a few practical issues where I'm interested in guidance on best practices. 1. Is there a publicly available central registry for common things like bus definitions? It feels like half of the idea of the standard is lost if everyone is pusing their own SPI, I2C, SDRAM buses and so on. 2. How do I treat variants of a bus? The most common bus we use is the Wishbone bus, and there are a few variants of it. It has seen at least thee revisions (called b2, b3 and b3) with signals added in each revision, and it also comes in different widths with 32 and 8 bits being the most common. It seems to me like I would need to create 3x2 = 6 different combinations to cater this. I'm also not sure what would be the preferred naming scheme for this. One way is to create six different versions (e.g. b3.8, b3.32, b4.8, b4.32... etc). Another way is to give different VLNV names to the different data width combinations (e.g. wishbone32 with versions b2, b3, b4 and wishbone8 with versions b2, b3,b4). I'm basically looking for best practices for this. 3. Are the bus definitions parametrizable? I'm using an Open source IP-XACT tool called Kactus2, and it doesn't allow me to set paramters for buses, but I haven't figured out if this is a tool limitation or if the standard prevents configuration. I have come across this issue for DRAM interfaces where I would like to vary address width, data width and so on to avoid having a myriad of similar buses. Best Regards, Olof Kindgren