Glad to be of some help.

I'll send you the minimal test benches I set up for some of the modules after work.

I recommend a simple, sometimes just clock and reset, test bench for all modules. This helps me isolate problems during development and then during integration.

_________________
Michael A.

Thanks for doing that. I never wrote a test bench specifically for ISim. I have forced a clock and then an active reset for a short period of time, by right clicking on each signal and the simulation worked...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Signs of life! I had to revert to an older core, the one without the register I/O bus modification, but all the features are still present. I've included the main files to construct a project in ISE. The project file grew to 7MB from older unused data so I chose not to upload that.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Sent you an update. Check PM for a zip with a corrected memory initialization file and the rudimentary test benches I generated.

_________________
Michael A.

Thanks for the testbench and finding the error in the .coe file!

The REGFILEINIT.coe file was incorrect for initializing the distributed RAM used for the Acc's, Reg's, Stack, zeropage pointer & stackpage pointer as it had comments I had included, which is not allowed. Now the .b core is functional again with the reg I/O bus.
It's interesting to note that after fixing that file and going back in and adding comments, it doesn't get stuck in the loop even after a cleanup of project files.
But this is good that all this has been straightened out after this 'bug' has been discovered after almost a year of hiding out. Last May 2012 is when Michael suggested the bus and I had put it into action... Updated Github.

I will put the .d core (with the multiplier opcodes) on the backburner but it will still occupy my thoughts. I'll give priority to completing a simple graphics computer on one PVB.

EDIT: Top speed is just abit faster passing a constraint of 11ns but it failed at a 10ns constraint for a top speed of 94MHz but this is just a project with the .b core cpu, blockRAM supporting zero page and stack, and address decoding. The minimum pixel clock will be at least 70MHz and I would like to run the CPU clk at the pixel clock rate. 24 MHz is a good margin to work with at this point as multiple Verilog modules still need to be added which will no doubt slow the overall speed.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

After adding all the modules necessary for a cpu to read/write the external SyncRAM which is acting as the videoRAM, it appears to be working! A small program to write 65K blue pixels to the start of the video memory works. I suspect the timing may be off somewhere though, can't get too excited yet.

Top speed is reported @87MHz which is a good margin with everything running at the 70MHz pixel clock.

There's alot of interference, so I'll try to qualify the videoRAM address decoding during hblank or vblank next.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Hurrah! Always good when these things spring into life.
Cheers
Ed

All I can say to those who yearn to learn, is to repeat the words of Winston Churchill, 'Never give up, never give up. Never, never, never."

At times I felt like the proverbial 'monkey behind the computer screen' trying to achieve Shakespeare during the .b core. Times after that, recently, where I questioned myself, "Am I learning anything even?"... I think I can say yes with confidence, I am learning... People in the forums are a great help.

EDIT: I had heard that quote on the radio recently, but I had quoted it wrong. From the source, out of respect:"This is the lesson: never give in, never give in, never, never, never, never-in nothing, great or small, large or petty. Never give in except to convictions of honour and good sense. Never yield to force; never yield to the apparently overwhelming might of the enemy." Well, in my case the enemy is the weakness of my own brain. It is good we remember history though!, accurately.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I am trying to make a video to post on youtube. It will show the .b core running @70MHz and sending first all red, then green, then blue pixels with a delay. Then it will show me changing the program, 'commenting out' the delays, and you can see the speed.
I estimate ~6 frames per sec, i.e. ~4MB/sec! At this point I will save the project and branch off to experiment further.

EDIT: replaced 'deleting' with 'commenting out'.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Truly amateur video!

Total 172MB upload, I hope it's not too large, or I'll have to compress the original .mov, it's in 720p. Says 18min's left.
It's been awhile since I used youtube. Things have changed.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Not so much luck with reading from the RAM yet. Quite abit of wrong data. First I clear the videoRAM, then I try to read, ORA, then write back. This is probably where I need to latch the data 1 cycle, probably even a half cycle, after the CPU wants to read in order to take the 6.5ns delay of the RAM into consideration.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Keep in mind that the RAM access time isn't the only delay. There's also the the pad output delay of the FPGA, and the pad input delay, plus delays of the traces on the board. These are specified in the Spartan datasheet (DS162, DC and Switching Characteristics).

I recommend first trying the design at a really low clock speed, so you know the timing is not an issue, and you can focus on the logic path.

To optimize for higher clock frequency, you need to add the right amount of wait cycles so that you're not reading too early (but you may be reading too late). Then, add the right amount output delay on the signals going to the SRAM so you're not reading too late. In the absence of a good board simulator, this will be a process of trial and error.

Good news! The whole system works @25MHz, 640x480 with no consideration for delays. I did a simple clear screen, read & ORA successfully. Will do more tests.


If I understand correctly, I need to present the RAM with the address, R/W & CS signal. Then on the port inside the FPGA read the data there with a delay?
Signal timings has always been my weakness in digital design.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

After you present the address and control signals, there's a small delay before the signals actually appear on the outside pins of the FPGA. This is because there's a relatively big capacitance of the output pin and drivers compared to the tiny capacitances inside the FPGA. Then the signal needs to propagate over the board to the SRAM, and then there's a delay from the SRAM before it presents valid data (this is the access time specified in the data sheet). Then the data needs to go back to the FPGA, and make it inside. Suppose this all takes 15 ns. Also, assume you have a 10 ns clock. Now, because your output is valid for a whole clock cycle of 10 ns, the data from the SRAM is also going to be valid for about 10 ns (a little less if different signals have different delays). So, if there was a delay of 15 ns, the answer is going to be valid between 15 ns and 25 ns. In this case, if you wait 2 clock cycles, you can grab the signal right in the middle of its valid period.

On the other hand, if the delay is 20 ns, the data is going to be valid from 20 ns to 30 ns. Now, if you grab the data at 20 ns, you'll be picking the front edge, and if you grab it at 30 ns, you'll pick the back edge. Neither is very reliable. So, the solution is to add an additional 5 ns delay in the address/control outputs using the IODELAY options of the output pads. This means the data will be valid between 25ns and 35 ns, and if you grab it at the 30 ns clock edge, you'll be in the middle again.

So, you need to pick the correct edge to read the data, and then you need to apply some additional output delay to make sure you read it in the middle of the valid interval. Lacking sophisticated simulations or high speed oscilloscopes, this can be done with a little bit of trial and error. Once you have established the correct cycle, you can move the IODELAY back and forth to find the edges of stability, and then pick a value in the middle.

Thanks! I will experiment with IODELAY and continue more testing.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502