In case of register modelling, why is FRONTDOOR accessing considered convenient when compared to BACKDOOR accessing of CSR. Is it because in case of BACKDOOR accessing we require accessing of HDL paths which is a cumbersome process. Is there a way we could make the BACKDOOR access simpler?
In reply to 100rabhh:
Who is saying this, FONTDOOR is more convinient than BACKDOOR? I doo not agree. FRONTDOOR is 1 access type and BACKdoor another one. You need BACKDOOR when accessing RO registers to write something in to this type of registers and it is less time consuming while not using bus access.
Front-door access is the “natural” way that the RTL accesses the registers, using a bus with a specific protocol defined for the bus.
Usually as a verification engineer there is less work to be done in the test-bench in order to support it.
Back-door access needs additional support to be added to the TB:
- You need to supply HDL_PATH of the registers, and keep in mind to make the path re-useable for higher levels.
- It can be tedious if you have un-conventional registers, for example: indirect registers.
So why Back-door access is needed if it adds additional work?
- It saves precious simulation time.
Imagine hundreds or even few thousands of registers to be written in order to configure
the initial DUT state of the block/IP/Full-Chip. It might consume 99% of your
simulation time, before actual traffic starts running and sometimes lasts for few hours (or even days, depends on complexity of the product).
Debug iterations will be extremally long, schedule of project will be bad. Daily job will be frustrating. - Some kind of registers cannot be written using front-door access type… So you need to load values into them using back-door access as chr_sue mentioned. Same thing is right for loading memories.
In reply to Michael54:
I’d not say frontdoor access is more easy to implement. You have to provide the bus2reg and reg2bus functions in the adapter. This is more effort then defining the HDL path. And frontdor access uses bus cyles to access the registers, i.e. it needs more clock cycles. But it is not slowing down the simulation.
backdoor access is the only way to deal with access limitations of the registers, like RO/WO registers.
Nobody is saying backdoor is the ultimate way to access registers. But there is an abolute need to have it.
In reply to chr_sue:
I agree regards the bus2reg and reg2bus. Forgot about it.
And agree regards registers which are restricted to only RD or only WR, you MUST add back-door support for it, no way to avoid it.
Regards simulation time:
Front-door access does consumes time, while backdoor consumes zero simulation time.
It is a matter of trade-off, if you have 10-100 registers and all registers are “normal” - I mean support both RD and WR access, the initial CONFIG_PHASE won’t last for long, so maybe there is no need in adding support for back-door access.
But if it is few thousands of registers and more of writes in the CONFIG_PHASE, each write multiplied in the duration of each write, it sums to substantial delay (especially for Full-chip/SoC levels) till actual DATA_PHASE(traffic) is started. So back-door support is blessed.
In reply to Michael54:
What I menat is frontddor does not have an impact on the simulation performance. The register access time depends on the bus cycles you have to execute for accessing 1 register. If 1 bus cycle needs 7 clock cycles this is an enourmous time effort.
In reply to chr_sue:
We can agree on next:
Front-door access is a MUST, no matter how long it takes accessing 1 register as it is the actual functionality of the RTL - which should be tested.
Maybe connections were wrong… These bugs should be revealed.
And you should add reg2bus, bus2reg and implement probably register access agent.
Back-door access is a MUST when you have registers of RO/WO access types and you want to write/read from it.
It can be nice addition in order to shorten simulation time, depends how many registers are present in the DUT.
Both Front-door/Back-door does not seem to have big impact on simulation performance, as far as I know, only have impact on simulation total run-time (clock cycles).
In reply to Michael54:
Hi Michael, Thanks for the detailed description, I kind of get it that BACKDOOR accessing saves a lot of our simulation time. Could you please shed some light on ways of say extracting HDL paths for these CSRs, in a design module there will be like 1000 more CSRs, is there a way we could extract the HDL paths and extract them correctly?
In reply to 100rabhh:
The number of the register does not matter. Important is how many different register cluster you have. If you have only 1 register block it is just easy. If you have hundreds it becomes costly.
If you are generating your RTL registers automatically you might be able add some functionality to your register utility to have an additiional output for the HDL path.