Jump to content

Taichi Ishitani

Members
  • Posts

    12
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Taichi Ishitani reacted to kock in How to interpret 'external' register type   
    Hi Taichi,
    If I understand you well, this can be described in an IP-XACT component as follows. Such a component has a memory map with an address block that describes internal registers. In addition the memory map needs a subspace map that references an initiator interface. The address space referenced by that initiator interface represents the external registers space. Here is the description:
    <?xml version="1.0" encoding="UTF-8"?> <ipxact:component xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ipxact="http://www.accellera.org/XMLSchema/IPXACT/1685-2022" xsi:schemaLocation="http://www.accellera.org/XMLSchema/IPXACT/1685-2022 http://www.accellera.org/XMLSchema/IPXACT/1685-2022/index.xsd"> <ipxact:vendor>accellera.org</ipxact:vendor> <ipxact:library>forum</ipxact:library> <ipxact:name>external_register</ipxact:name> <ipxact:version>1.0</ipxact:version> <ipxact:busInterfaces> <ipxact:busInterface> <ipxact:name>T</ipxact:name> <ipxact:busType vendor="v" library="l" name="n" version="v"/> <ipxact:target> <ipxact:memoryMapRef memoryMapRef="MM"/> </ipxact:target> </ipxact:busInterface> <ipxact:busInterface> <ipxact:name>I</ipxact:name> <ipxact:busType vendor="v" library="l" name="n" version="v"/> <ipxact:initiator> <ipxact:addressSpaceRef addressSpaceRef="AS"/> </ipxact:initiator> </ipxact:busInterface> </ipxact:busInterfaces> <ipxact:addressSpaces> <ipxact:addressSpace> <ipxact:name>AS</ipxact:name> <ipxact:range>'h80</ipxact:range> <ipxact:width>32</ipxact:width> </ipxact:addressSpace> </ipxact:addressSpaces> <ipxact:memoryMaps> <ipxact:memoryMap> <ipxact:name>MM</ipxact:name> <ipxact:addressBlock> <ipxact:name>internalRegisters</ipxact:name> <ipxact:baseAddress>'h0</ipxact:baseAddress> <ipxact:range>'h80</ipxact:range> <ipxact:width>32</ipxact:width> </ipxact:addressBlock> <ipxact:subspaceMap initiatorRef="I"> <ipxact:name>SM</ipxact:name> <ipxact:baseAddress>'h80</ipxact:baseAddress> </ipxact:subspaceMap> </ipxact:memoryMap> </ipxact:memoryMaps> </ipxact:component> If you instantiate this component in an IP-XACT design and connect bus interface I to another component instance, then the memory map (containing the external registers) referenced by the connected target interface is mapped into the address space AS. In this way, from target interface T, the internal registers are accessed at offsets 'h0 -'h7F and the external registers are accessed at offsets 'h80 - 'hFF.
    Best regards,
    Erwin  
  2. Like
    Taichi Ishitani reacted to kock in How to interpret 'external' register type   
    Hi Taichi,
    There is no semantic consistency rule that an address space (or address space segment) that is mapped a subspace map into a memory cannot overlap with an address block. However, an address block does represent a "contiguous" piece of memory so in my opinion it would a good practice to split the address block.
    Best regards,
    Erwin
  3. Like
    Taichi Ishitani reacted to Bas Arts in RgGen: Open source CSR generation tool   
    Hi Taichi,
    Did you consider to use the IP-XACT register specification format as input for your generator? Any specific reason to use yaml and your own (?) specification format? Just curious.
    -- 
    Bas
  4. Like
    Taichi Ishitani reacted to sas73 in New UVM Reference Implementation Now Available   
    2 days! That's fast response
    Exactly!
    If you're not open in the design/pre-release phase you're likely to miss use cases and if the members have committed themselves to solutions  and switched their focus to other tasks I imagine that there will be an unwillingness  to go back and redo things even if new important insights have been revealed.
    I think most users would like a code base they can build upon, not one that needs adaptations to make it work. Being fully transparent about the code in the making will reduce the risk for such adaptations
    What I'm suggesting is free and efficient access to the collective intelligence of the entire community at a point in the development cycles where it makes the most difference. I'm not suggesting a shift in the rights to make the final decisions. That's exclusive to the paying members. What's preventing this from happening within Accellera?
  5. Like
    Taichi Ishitani reacted to sas73 in New UVM Reference Implementation Now Available   
    Unfortunately I'm not with a member company. I was hoping that I'd have read permissions regardless of my current affiliation. As a user I'd like to see the connection between discussions in the official forum, the issues reported to the issue management system, and the code being developed in response to that. The ability to immediately test that code and possibly give feedback as code comments or a pull request. More like Github, Gitlab and other platforms. Seems to me that this would be a more efficient way to give and get user feedback.
×
×
  • Create New...