Taichi Ishitani

Hi Erwin, Yes, I understood. However splitting the memory map would make the generator complex so I'd like to define an addressBlock and a subspaceMap like below. addressBlock: 0x00 - containing register_a and register_c subspaceMap: 0x10 - 0x20 containing register_b From this comment, I think this allocation is also valid allocation. Is my understanding is correct? Regards, Taichi Ishitani

Thank you for your advice, Erwin. I have an additional question. Can I use this way in the case that the external address range is in the middle of internal registers range? For example: register_a address: 0x0 internal register register_b address: 0x10 - 0x1F external register register_c address: 0x20 internal register These registers (regsiter_a, register_b and register_c) are in the same CSR block. For this case, do I need to split the memoryMap into 3 address range like below? addressBlock: 0x00 - 0x0F containing register_a subspaceMap: 0x10 - 0x1F containing register_b addressBlock: 0x20 - containing register_c Regards, Taichi Ishitani

Hi, I'm developing CSR generation tool named RgGen and planing to IP-XACT generation. https://github.com/rggen/rggen RgGen supports the 'external' register type. An address range described as an external register is connected to other CSR block. For this exmaple, 'register_17' (address range: 0x80 - 0xFF) is an external register and this range is connected to other CSR block. When generating IP-XACT, it's unknown which CSR block will be connected to this range. How should I interpret this case into IP-XACT? Regards, Taichi Ishitani

Erwin, thank you for your comment. I understand that the indirectinterface element is not suitable for the above exmaple. I will consider another interpretation.

Hi Erwin-san, Thank you for your feedback! From this description, I think only one bit field can be specified as the index field. So I'm wondering whthier or not an indirect interface can be used for an indirect register which has multiple index fields. For the above example, the 'regiter_11' register uses 'register_0.bit_field_0' and 'register_0.bit_field_1' bit fields as its index fields. Regards, Taichi Ishitani

Hi Bas, I'm planning to add IP-XACT support. But I have no experiences using IP-XACT so I'm looking into the specification now. I think XML is not readable nor maintainable format for human so I chose the formats below. Ruby with description API Structured text (YAML, JSON, TOML) Spreadsheet (XLSX, ODS, CSV) Regards, Taichi Ishitani

Hi, I'm developing CSR generation tool named RgGen and planing to IP-XACT generation. https://github.com/rggen/rggen I'm wondering how to interpret RgGen's CSR description into IP-XACT. RgGen supports the indirect register type of which accessibility is controlled by other bit fields. Eexample: register { name 'register_11' offset_address 0x50 size [2, 4] type [:indirect, 'register_0.bit_field_0', 'register_0.bit_field_1', ['register_0.bit_field_2', 0]] # bit assignments: [ 7:0] [23:16] [39:32] [55:48] bit_field { name 'bit_field_0'; bit_assignment lsb: 0, width: 8, sequence_size: 4, step: 16; type :rw; initial_value 0 } # bit assignments: [15:8] [31:24] [47:40] [63:56] bit_field { name 'bit_field_1'; bit_assignment lsb: 8, width: 8, sequence_size: 4, step: 16; type :rw; initial_value 0 } } The register_11 register is an array register and its array size is 2 x 4. A sub-element of this register is selected by bit fields 'register_0.bit_field_0' and 'register_0.bit_field_1'. In addition, the 'register_11' can be accessed only when the bit field 'regiter_0.bit_field_2' is 0. For this case, do I need to use the 'mode' element and 'alternateRegister' element to interpret this kind of regiter? Regards, Taichi Ishitani

Hi All, I'm developing an open source CSR generation tool named RgGen. https://github.com/rggen/rggen By using RgGen, you can generate UVM RAL models, RTL, C header files and wiki documents from readable register map specifications. This is a sample register map specification describing a CSR block for an UART IP. https://github.com/rggen/rggen-sample/blob/master/uart_csr.yml RgGen can generate source files listed below from this specification. UVM RAL model https://github.com/rggen/rggen-sample/blob/master/uart_csr_ral_pkg.sv RTL https://github.com/rggen/rggen-sample/blob/master/uart_csr.sv https://github.com/rggen/rggen-sample/blob/master/uart_csr.v https://github.com/rggen/rggen-sample/blob/master/uart_csr.vhd C header file https://github.com/rggen/rggen-sample/blob/master/uart_csr.h Wiki document https://github.com/rggen/rggen-sample/blob/master/uart_csr.md

Hi, To avoid this error, you need to access the other word of the register. For example: FOO register (address range 0x00 - 0x07) 1st access: 0x00 In this case, you need to access 0x04 before accessing 0x00 again. If you access 0x00 before accessing 0x04 then you will get "[REG_PREDICT_COLLISION]" error. Regards, Taichi Ishitani

How about printing objection information? For example, list of components locking objection. Regards, Taichi Ishitani

Hi Chris, You mean that uvm_reg_predictor includes a bug, right? Regards, Taichi Ishitani

Hi all, I have a question about behavior of uvm_sequence_base::kill method. In case of virtual (layered) sequence, how should be uvm_sequnce_base::start task invocation of lower layer sequences when uvm_sequece_base::kill method is invoked? Should be finished completely? Can be terminated suddenly? I attached an example code. If start task invocation of lower layer sequences should be finished completely, both of uvm_info within innter_sequence and uvm_info within outer_sequence should be displayed. However, when I executed this sample code with the latest VCS, uvm_info within innter_sequence was not displayed. Regards, Taichi Ishitani process_test_uvm.sv