Forum Discussion
Occasional ContributorFailing IO buffer
Occasional ContributorHello again, Having read the EEPROM data sheet, I read it as only doing a page write if a subsequent word is presented within 150us of the first. In my case i only write one byte so there should only be one write cycle lasting for 100ns. The results I get confirm that the write and read are both successful and that the read data travels through the IO buffer correctly. I see no reason for the receiving instance should not read the incoming data but that is what is happening. Hence this plea for help.
Regarding the clock, the only choices available are the .cmp, .irc and_inst.vhd files. (I am using Q13.1). I can rebuild the clock if necessary but would that help in this instance?
Regards
Ken
Super ContributorHi Ken,
how do you verify that "the write and read are both successful and that the read data travels through the IO buffer correctly". According to AT28C64B datasheet, the device won't replay written data before internal copy to nonvolatile memory has finished. It even doesn't reflect previous EEPROM content but sends toggle bit and data polling info on two data lines (IO6 and IO7).
PLL *.qip and HDL files are generated by PLL MegaWizard in any Quartus version. .qip may link to a subfolder but at least Clk_16MHz.qip is located in your projects project folder, look into base_top.qsf.
Regards
Frank
- KenBee
I use an oscillosope to verify all signals. I stop the instance from running (FSM 'Spin') and check the data pins on the EEPROM, the pins on the FPGA - DataIn bus, and the output DataCheck. The DataIn bus reads correctly, so I know the buffer is passing the data from EEPROM correctly. But the DataCheck, which should be a copy of the DataIn bus, is all highs.
As an aside, I changed the write time to 10ms but it has made no difference.
Regards
Ken
- FvM
Advancing the states manually may give enough time for EEPROM to finish store operation. But MMU.vhd has to features to stop FSM, thus we can't determine if your way of testing has side effects, e.g. preventing DataCheck gettin the expected data.
- KenBee
As a sanity check I recreated a similar project using Prime Lite. Exactly the same result - good data stands on the MemDataIn bus but is not read in. To stretch things a little further I removed the 'Spin' state and added two new states to create a pulse generator. The pulses are good but the MMU still will not read the incoming data. I am totally baffled as to how Quartus manages to screw up this simple command.
