New ContributorA very simple desiggn to trap failure. Using an IO buffer (8 off) I have proved that the input from an EEPROM is read corrcly but the recieving instance's register records X"FF". I cannot see why. Any help would be appreciated because it is driving me nuts.
Super ContributorCan you show code, a project, Signal Tap output, anything? Not much to go on here. Also include target device and Quartus version.
New ContributorI am using Quartus 13.1 with a Cyclone IV. I am happy to send the .bdf and .qsf but have difficulty in getting them into this reply. I use an oscilloscope to monitor the signals so I have never used Signal Tap. Could you please tell me how to send the data? When I tried to attach the .bdf it was refused. I guess the format is wrong.
New ContributorCan you use these?
Super ContributorHi,
PLL IP is missing in the design files. After adding a PLL with expected parameters, the design compiles and also "works" in simulation, when connecting a memory device that replays written data.
I see however several possible problems:
Regards Frank
New ContributorTHnak you for responding. Perhaps I should explain a short history as to what I am trying to achieve. I created a complete PCB and expected it all to work - it did not. Eventually I tracked the fault down to data not being read in from the EEPROM. At that time I used the simple approach of writing to the EEPROM (AT28C64B), set the ouput buffer to tristate and then reading data in as required. This worked fine when I last used Quatus v7.2 fifteen years ago. Since I had to move to version 13.1 I presumed there was a possible problem to using this approach so I added the IO buffers. Still no good. Since I was not sure as to whether the buffer was working correctly or not I added the monitor bus. This proved that the data was written into the EEPROM correctly, and, by holding the FSM in the read state I could see that the correct data was on the EEPROM output pins, the data was correct on the buffers' read in 'pins' but the raeding instance was seeing all highs. This whole little project is to try and trap the cause of the problem. It is stopping me from creating the real project.
Regarding the PLL IP I would assume the megafunction would take care of itself. I do not see what I can do about that. The EEPROM works as it should. The FSM only runs once so that I can 'scope the lines in a steady state. How do I set synchronous reset release? I have enabled the 'DEV_CLRn' if that is any help.
I don't know if any of this helps - I can only hope so.
Regards
Ken
Super ContributorHi Ken,
as stated, the code doesn't work for EEPROM. After a byte write, page data is written to nonvolatile memory after 150 us of write inactivity. Page write takes typically 2 ms, review AT28C64B datasheet. You'll need to wait for end of page write to be able to reread written data.
Regarding PLL, Clk16MHz.qip and Clk16Mhz.v or *.vhd are missing.
Regards
Frank
New 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
