NAND Interruption Trigger Module

[nbstrong]

To facilitate research, the controller needs to be able to be interrupted so that we can drive signals onto the NAND signals at specific times. This should be a branch of its own and not be merged into master.

I feel like this can be an added module in the nand_avalon wrapper with its own registers. It will mostly control a mux for the nand signals and perform monitoring on them. I have a rough state machine and register map drawn up that could accomplish this.

[nbstrong]

I anticipate the tricky bit for this design will be inserting multiplexers on the nand signals. The inner IO unit module already inserts tri-state buffers on these lines. Tri-state buffers have to happen on the FPGA pins, so I don't know if it will error if we try to add a multiplexer between the pin and the tri-state buffers or if the tool will optimize correctly and place the tri buffers last in the signal chain.

If it errors, will need to move the tri-state buffers to after the mux, before the pins out, and have a "tri-state enable" control line that comes out to them.

[nbstrong]

Register Explanations: Trigger and Trigger Mask - Wait Trigger state will advance when NAND Signals = Trigger Register. Trigger Mask will exclude specific bits from being used in this comparison. For the 2nd trigger (and if any more triggers are needed), if the Mask is 0 then the state machine will advance through that state to the next one.

Delay - Will be the starting value for a 32 bit counter. Once entering Delay state, counter will begin counting. Once counter reaches 0, state machine will advance.

Drive and Drive Mask - These registers will be attached to FIFOs to allow multicycle custom pattern to be driven onto the NAND signal lines every cycle. Drive Mask register will allow the nand_controller to drive the signals instead of this interrupt module. Once the state machine enters the Drive state, the FIFOs will start emptying. Once the FIFOs are empty the state machine will return to IDLE state.

[nbstrong]

It will need control and status registers.

For control, it will need a bit to advance from IDLE -> WAIT_TRIGGER. Potentially also a bit to force it to trigger to advance from WAIT_TRIGGER -> DELAY. It will need a reset bit. Potentially a FIFO flush bit.

Status will need a status bit to determine what state it is in. FIFO empty/full bits.

[alexmilenkovich]

Here are my comments regarding future controller extensions (what is currently on my wish list).

Extension #1.

Timing operations on the flash array. Add a private counter that will allow measuring duration of common operations such as page program, page read, and block erase. The timing these operations should be understood in a narrow sense of the word - the counter should be cleared and should be counting up every clock cycle while the Ready/Busy signal is low (the flash array is busy). Please note that this operation does not involve transferring of data to/from the nand chip. A 32-bit counter should be sufficient. Programmer's view: The status register can be modified to add a bit that will indicate that there is a new value in the counter. The counter will be exposed on the Avalon bus.

Related functionality: timing transfers from the buffer to the chip and vice versa.

Extension #2 .

In many experiments we interrupt page program, page read, and block erase operations. As we emulate physical interface to the chip we achieve this by controlling the host software: starting an operation, idling for the specified period of time, and then sending an ONFI RESET command. Often, we monitor Busy/Ready to precisely determine the duration of this interrupted operations (there is a time difference between sending a command and chip responding to it - it's a function of the internal state machine on the chip).

One useful function is that we add NEW ONFI commands - e.g., PARTIAL PAGE PROGRAM, PARTIAL ERASE, PARTIAL PAGE READ. With this extension, you would initialize a counter that carries information about the operation duration and then issue the command. The controller would count down and when it reaches 0, it would automatically issue a RESET command to the chip. This would require adding new commands and an additional counter (I would use a separate counter for this and keep from 1 active even for this kind of operations).

Extension #3.

Once all low-level interface functions are testing in Altera Monitor Program, writing a Linux device driver for the ONFI controller would make this a very useful project.

[nbstrong]

Here are my comments regarding future controller extensions (what is currently on my wish list).

Extension #1.

Timing operations on the flash array. Add a private counter that will allow measuring duration of common operations such as page program, page read, and block erase. The timing these operations should be understood in a narrow sense of the word - the counter should be cleared and should be counting up every clock cycle while the Ready/Busy signal is low (the flash array is busy). Please note that this operation does not involve transferring of data to/from the nand chip. A 32-bit counter should be sufficient. Programmer's view: The status register can be modified to add a bit that will indicate that there is a new value in the counter. The counter will be exposed on the Avalon bus.

Related functionality: timing transfers from the buffer to the chip and vice versa.

Seems simple enough. Clear and start counting when RNB goes low. Stop counting and assert a status bit when RNB goes high again. Clear status bit on read. Output counter to a read only register.

Extension #2 .

In many experiments we interrupt page program, page read, and block erase operations. As we emulate physical interface to the chip we achieve this by controlling the host software: starting an operation, idling for the specified period of time, and then sending an ONFI RESET command. Often, we monitor Busy/Ready to precisely determine the duration of this interrupted operations (there is a time difference between sending a command and chip responding to it - it's a function of the internal state machine on the chip).

One useful function is that we add NEW ONFI commands - e.g., PARTIAL PAGE PROGRAM, PARTIAL ERASE, PARTIAL PAGE READ. With this extension, you would initialize a counter that carries information about the operation duration and then issue the command. The controller would count down and when it reaches 0, it would automatically issue a RESET command to the chip. This would require adding new commands and an additional counter (I would use a separate counter for this and keep from 1 active even for this kind of operations).

Does this need new commands?

Could just have a counter that can be loadable and when activated begins counting down at the next command and when 0 asserts a signal that jumps the controller's state machine to the RESET command.

This would enable it to support any command. Software would have to store the operation durations unless you wanted some RAM.

Extension #3.

Once all low-level interface functions are testing in Altera Monitor Program, writing a Linux device driver for the ONFI controller would make this a very useful project.

Ok, would take some research though. I've written some simple drivers for this but not sure how they are different than Linux drivers.

[nbstrong]

If you'd like to measure some specific operations we could add some custom counters for those as well.