custom peripheral registers

Two simple choices:

1) Implement the by by instantiating the vendor's flip flop with clear. Processor drives data and enable, peripheral drives clear.

2) Describe the desired behaviour of a register: At clock transition if processor is writing, set to 1. Else if peripheral is done, set to

1. Otherwise, do nothing...

That's assuming you are willing to follow a rule in software of never writing the bit without first checking to make sure its cleared. And assuming your peripheral can't clear it until at least a few clocks after it's been set. And assuming your processor and peripheral share a clock; if any of these aren't true, it's a little more complicated.

I've done this exact thing in a couple IP cores. All that follows assumes that you are using the Create and Import Peripheral Wizard's template modules. I use the verilog stub logic (user_logic.v) so if you use VHDL, you will have to figure out the coding differences.

The first assumption that I made was that the software would set the bit and then wait until that bit is cleared before doing anything else (usually a while loop). The IP core gets triggered by the register bit being set to a 1. The core goes off and does its thing. When it is done, and the trigger bit needs to be cleared, I assert a signal (from the IP core) high for several clock cycles. An additional 'else if' statement is added to the slave register implementation in the user_logic module such that, at the assertion of the aforementioned signal, the register is written with whatever you want to put in there. In this case, you just want to clear a bit so you can set that to 0, or just set the whole thing to 0 if you don't care about the other bits. If you have set up the software correctly it will 'see' that the bit is cleared and go on and do its thing. If you are immediately writing the trigger bit to a 1 after it is cleared, you'll have to be sure that your IP is done 'pushing' data into the register before the OPB tries to write to it. If simple guesswork fails, simulation can help figure out the timing.

I have done this when the OPB clock and the IP clock are the same and when they are different. If they are different, you just have to sync the IP signal into the OPB clock domain before you use it to push data into the slave register. The following is a snippet of code for the slave register (common clocks):

// implement slave model register(s) always @( posedge Bus2IP_Clk ) begin: SLAVE_REG_WRITE_PROC

if ( Bus2IP_Reset == 1 ) begin slv_reg0 this is the signal from the IP that stays high for a few clocks (I think 4) begin slv_reg0 the rest of the register code follows this, unaltered from the template.

Hope this helps. It is a pretty easy and usable way to do what you are trying to do.

Sorry. Formatting screwed up : )

Here's the code without comments.

// implement slave model register(s) always @( posedge Bus2IP_Clk ) begin: SLAVE_REG_WRITE_PROC

if ( Bus2IP_Reset == 1 ) begin slv_reg0

Look at the IPIF examples, because that is what you are ultimately trying to build. You specify how many registers to reserve, and then you connect the registers to your design. Alternately, you can do the address decoding further down, but it's pretty easy to let the IPIF layer handle it.