• Content count

  • Joined

  • Last visited

About olofk

  • Rank

Profile Information

  • Gender
    Not Telling
  1. Ah! That is a much better solution. Hope to see things moving in this direction
  2. @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.
  3. 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?
  4. 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