petermonsson Posted October 3, 2010 Report Share Posted October 3, 2010 Hi all, I've seen that UVM will use VMM RAL as the base for the register package. I'm really happy about that as I love VMM RAL and use it daily. RAL has its problems, but most of them are related to documentation (I plan on documenting the undocumented features as soon as I find out what they do) or can be worked around. Unfortunately there is one serious problem that annoys me on a weekly basis: All read method calls as well as derivatives thereof (such as peek) have the following prototype for the data: output bit [`VMM_RAL_DATA_WIDTH-1:0] value Why, oh, why didn't they make it logic? vmm_rw_access and vmm_rw_burst use rand logic [`VMM_RW_DATA_WIDTH-1:0] for data, but for no apparent reason vmm_ral_access, vmm_ral_reg, vmm_ral_mem, etc. convert it into a bit vector thereby swallowing x's (turning them into 0's) and making bug hunting of both testbench and RTL a pain. The only (broken) workaround that I've found is to add the following line to my vmm_rw_xactor: if (|tr.data === 'x) `vmm_error(log, "Found x in return data"); which only works if you never expect to see undefined values in any kind of register. I know that this is quite a bit of work, but I believe in it enough to be willing to patch the code myself if you allow me to (I am aware of the subtle changes that need to be made to the vmm_ral_tests and ralgen, etc.) Anyway, that was my opinion about the subject. How do you all feel? Best Regards Peter Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.