commandos Posted May 16, 2015 Report Share Posted May 16, 2015 Hi, I have implemented a uvm reg block containing several uvm reg's. What I want to model is register reg_a has the following layout: {fld_a, fld_b,fld_c} and register reg_b has: {fld_st,fld_rsv} The read return of reg_a has fld_b and fld_c as is, while the fld_a value of read data is dependent upon the value of reg_b.fld_st: If reg_b.fld_st = 0, the read data of reg_a is {0,fld_b,fld_c} If reg_b.fld_st = 1, the read data of reg_a is unmodified. I think I need a post_read task implemented for reg_a, but could you please let me know where I should put it? The scope of accessing both reg's should be at reg block, but I don't know how to add a callback there to achieve this. An example is much appreciated. Thank you. commandos 1 Quote Link to comment Share on other sites More sharing options...
tudor.timi Posted May 16, 2015 Report Share Posted May 16, 2015 The post_read(...) function is only called when you do an actual rg.read(...) inside a sequence. If you have explicit prediction set up (where the contents of a register are computed based on transactions coming from the bus monitor and not from the register sequences), then you'll need to implement this using post_predict(...). I've written on the topic of how to implement fields with custom access policies here. The concepts should transfer over to your problem (you'll just need different implementations of the post_predict(...) method to handle your behavior). Try it out yourself and if you get stumped, post again here. It you solve it, it would also be cool to post some notes here so others could benefit. Quote Link to comment Share on other sites More sharing options...
commandos Posted May 25, 2015 Author Report Share Posted May 25, 2015 The post_read(...) function is only called when you do an actual rg.read(...) inside a sequence. If you have explicit prediction set up (where the contents of a register are computed based on transactions coming from the bus monitor and not from the register sequences), then you'll need to implement this using post_predict(...). I've written on the topic of how to implement fields with custom access policies here. The concepts should transfer over to your problem (you'll just need different implementations of the post_predict(...) method to handle your behavior). Try it out yourself and if you get stumped, post again here. It you solve it, it would also be cool to post some notes here so others could benefit. Thanks for your help. I have read your post and another post from other member which I thought to be relevant http://forums.accellera.org/topic/980-what-is-the-proper-way-to-trigger-something-when-a-uvm-reg-field-is-written/ I do have one more question related to the link you provided. Do you mean that for such purpose I should implement post_predict in callback only? Do I still need to implement corresponding post/pre_write/read methods? (I have bus adapter and predictor hooked on with a bus monitor, and I configure it as explicit prediction by turning off auto_predict.) Kind regards, Quote Link to comment Share on other sites More sharing options...
tudor.timi Posted May 26, 2015 Report Share Posted May 26, 2015 Yes, you'll just need the post_predict(...) callback. Whether or not you have explicit prediction turned on only changes who calls the register's predict(...) function. For auto-prediction, predict(...) gets called by the address map in response to a register read(...) or a write(...). In explicit prediction mode, the reg predictor calls predict(..) when it receives a bus transaction. The pre/post_read/write(...) callbacks only get called in response to a call to read/write(...) inside a register sequence. I haven't really found any use for them yet. Long story short: read/write(...) for stimulus, predict(...) for reference modeling. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.