Collision detected for register in UVM register model

[meenu]

Hi

I have a register model which has registers of width 32 and 64. The data width and address width are both 32 of the AXI interface. I m using a predictor to update the register model with the current state of the registers of the DUT.

When i make an attempt to write to a 64bit register, the data is automatically sent as two bursts of single transfers. ( Is this the register model internal working?)

I have set length =1 ( single transfer) and size =WORD(32bits)

Read also happens in two bursts.

I have implemented a monitor which monitors the transactions. It assigns the attributes of the monitor burst to the master burst and sends it to the predictor.

It works for 32 bit registers. But when i try to write to/read from a 64 bit register, I get an error from the predictor "[REG_PREDICT_COLLISION] Collision detected for register rm.AWE

where rm is the register model

and AWE - 64 bit register

Has anyone faced this error before?

What is solution to this?

[janick]

The register model indeed performs the two-transfer operation when reading/writing a 64-bit register over a 32-bit bus. That's what the abstraction is all about so you can change your bus width later and your tests will still work.

The predictor will want to see a complete register access (i.e. two individual operations) to perform the prediction. It apparently saw two partial accesses to the same sub-register.

[meenu]

Hi Janick

I did not exactly get what you said. I can understand that it performs the two burst operation when it reads/ writes a 64 bit register over a 32bit bus.

How is it possible to perform two individual operations on the 64bit register?

For eg: If i would like to read the value from a 64bit register AFE written with data =64'hFFFFF_FFFF_FFFF_F000 . The start address of AFE being 24.

I issue a read:

rm.rf.AFE.read(status,data) and the first read burst would contain the data 32'hFFFF_F000 and this is what the monitor would get as the first monitor burst. In my monitor, i assign this to a burst of type axi master burst and send it to the predictor. The address of the first burst would be 24. The second read burst contains the data 32'hFFFF_FFFF and the monitor receives it and assigns it to the master burst's data which is sent to the predictor. This time the address would be 28 (24+4). Probably when it sees two addresses for the same register AFE, it reports a collision detection.

What is the solution to this?

[janick]

Is your monitor returning a single AXI burst transaction for the 64-bit read or two 32-bit single-transactions?

[meenu]

Two 32bit transactions is what it returns. In that case a collision each is detected for both read and write.

[janick]

Are the individual transactions interleaved or does one 64-bit operation complete before the next one is started? i.e. does your monitor report/sees RD32, RD32, WR32, WR32 or RD32, WR32, RD32, WR32?

[meenu]

I do a write first followed by a read. So my monitor sees and reports WR32,RD32,WR32 and R32.

[janick]

That's your problem! Register accesses are supposed to be atomic and the predictor must see RD32, RD32, WR32, WR32 or WR32, WR32, RD32, RD32

[meenu]

Hi Janick

1) In order to ensure that read happens only after write completes, I provided a delay between issuing the write and read task calls. And now the monitor sees WR32, WR32, RD32, RD32 and the same is sent to the predictor. There is no collission error. But what does collision error actually imply? Thanks for the fix.

2)Either read or write, i send the data to the predictor from my monitor. But when the direction is read, i trigger an event ->read_done. After the read task call, i wait for the event @read_done, and try to get the data via reg.get(); ,but the data is always zero. In case of 32bit read operations, the data obtained via reg.get() is proper. Does not this imply that the predictor does not update the register model properly in case of 64bit operations?

[meenu]

Hi

2) gets solved, the updation takes some time and introducing a delay before the sampling point after the trigger solves the problem

Thanks !

[janick]

But what does collision error actually imply?

The explicit monitoring prediction works at the register level. Thus the predictor collects all of the RD or WR accesses to the entire register before performing the prediction. The collision indicated that an address that was previously accessed in a yet-to-be-completely-collected register access has been accessed again.

[meenu]

Okie that makes sense to me now.

1) Other than introducing a delay between the write_reg and read_reg, is there any other method to allow the write to complete before the read. I do not think there is any ordering possible between write and read operation without the delay introduction.

2)Just like a 64bit data is split into two 32bit bursts by the reg model itself, is this abstraction extended to 128bit, 256 bit or 512 bit registers as well. I mean to ask is it possible to write to a 128bit register with a data bus of width 32bits via a register model using the same adapter? For eg: is a 128 bit data intended to be written into a 128bit register split into 4 bursts by the model internally?

[janick]

1) It may be possible to "fix" it by making sure the delays in the monitoring path is shorter or equal to the one in the stimulus path. That's in the register model integration layer and the bus agent.

2) Yes, that's how the register abstraction layer works.

[meenu]

I have created a second register block which consists of registers of widths 32,64,128,256 and 2048.

1)After the proper integration, i get an error that the UVM_REG_DATA_WIDTH should be 2048 or higher.I set it to 2048 and i do not get the error anymore.

2)I m using the cadence AXI UVC. When i do a write sm.sf.ABA.write(status,data) where data is a 32bit value FFFFF07, the adapter reg2axi gets the burst, but i get an error that the strobe value F is invalid. I have set the strobe as F so that all 4 bytes of data get written. These same settings in the adapter function works for the previous register model. The new register model also has an address width and data width of 32. The burst is ignored since the strobe value is invalid and write does not happen.

3)The monitor receives a 32bit read burst instead of the write, though i perform a write and though the address of the ABA register is 07, it reads from address 7B80.

If i perform a read after write, the write burst is ignored because of the invalid strobe, and the monitor receives two read bursts instead of a write followed by a read and both are different addresses. The first one being 7B80 and the second one of a lower address.

Any idea on what is happening?

Edited April 24, 2012 by meenu