6502.org

Hi Grant,

I've been collecting components slowly and just received my USB Blaster today so I'm getting closer. Just a couple questions, please?

1> Which Quartus II 13.0sp1 components do I need to download?
2> USB Blaster uses which connector on the Cyclone II board? AS or JTAG?

Thank you.

Cheerful regards, Mike

Hi Mike.
All you need are the core download ("Quartus II Web Edition (Free)") and the cyclone devices ("Cyclone II, Cyclone III, Cyclone IV device support (includes all variations)").
You can "un-tick" the other devices unless you want them.

Very big download, unfortunately. Thankfully I am on a 76Mbps link

Regarding the connector, the JTAG is the one for quick programming (and the default set in Quartus) to allow a configuration to be uploaded and to remain until power-off. The "Active Serial" port is used when you want to store the configuration onto the on-board flash ROM so that it will power-up with that configuration without needing to upload it to the board each time.

So, JTAG is for messing about with, and Active Serial is to keep it

See my earlier post on this thread to see how to use Active Serial programming -any questions or probs, please feel free to contact me.


Regards.

Grant

So I use the JTAG connector on the Cyclone II board for both "jtag" and "active serial" type uploads, correct?

Does the Quartus download screen below look ok?

Thank you, Grant.

Cheerful regards, Mike

No, to use JTAG plug the blaster into the relevant port, then swap the connector to the AS port if you want to use active serial. The USB Blaster is used for both.

Yes, the download screen is what is needed, but you can un-tick the modelsim if you won't be using it (not needed for development).

Regards.

Grant

oh my goodness... "AS" stands for "Active Serial"...

Thank you for your patience, Grant.

Hi Grant. I've been doing a FPGA conversion of your code to a newer Cyclone IV, question I have is, Do I need to change any of your code other than pin assignments?

Bill Nobel

Hi Bill.
No changes apart from the pins would be necessary assuming you have the same clock speed.

If you have a different clock then either change the relevant timing values (a bit tedious) or introduce a PLL into the design.

ie. in_clk ------> PLL logic ------> 50MHz clk

Regards.

Grant

Hi..Just wondering ..

instead of using sram (for external RAM).. I've got a cylcone IV type board ..that has on board SDRAM .. Has anyone used Grants design with SDRAM option?..trying to find SDRAM vhdl code (or core) is rather very confusing.. being newbie to VHDL .. does not make much sense and I cannot see how easily to go about it..

The board came with a test option for the SDRAM... but not sure how to integrate that code with this FPGA computer.

For now I was able to transfer the code from cyclone II to IV to run on this board using on chip ram .. I can get 32K ram out of FPGA .. so without the SDRAM it is still pretty good .. I'll see if I can attach the vhdl code for the SDRAM test.

Please note that the fpga chip is actually EP4CE10E22 ...

6522 VIA or 6532 RIOT for FPGA computer?

To extend the capability of this project .. implementation of a 6522 or even 6532 would be great addition.. In that case systems like the SYM-1 ..that have software dependent on peripheral I/O for comms ..could also be ported

I've tried looking for code for these ..the best I can find is this link..
http://passionoric.free.fr/eng/frameng.htm
http://passionoric.free.fr/eng/download.htm

Again from my amateurish start with VHDL ..not sure how to integrate the code and make it part of the say UK101 6502 FPGA computer

(Note that SDRAM is a bit of a handful - I think you need a non-trivial controller to drive it. Arlet's done it, and perhaps Rob has too. If you just want to make use of the SDRAM you already have, and you don't need spectacular performance, that should be possible.)

I got the SDRAM working on a Terasic DE2-115 board a few years ago when I was playing around with soft-core implementations of the 6502, 6809, and 68K. If you're still stuck, I'll dig up the module this evening and make it available to you. I will warn you that it's written in Verilog however. But you can mix the two languages freely with Quartus with no ill effects other than possibly to your brain.

Here is my Verilog code for SDRAM, consisting of the SDRAM controller itself, and the CPU/Video interface. The video interface is a high priority read-only channel for the video generator. If you don't need it, just tie the vid_rd_req to 0 input. Note that the SDRAM interface exposes a 256 byte window to the SDRAM memory, located in page Axxx, but that's easily changed to suit your needs.

Added: please note that the SDRAM interface fits to my 6502 core, which means that it uses a single positive edge clock, and that a memory read, with address valid on cycle 't', has read data valid on cycle 't+1'.

I just use the vendor supplied SDRAM controller. SDRAM controllers are complex enough especially when dealing with DDR2 or DDR3 DRAM and the timing can be difficult to get working at high performance, that I just prefer to use what's already supplied. It takes a bit of research to figure out how to use the controller, but it's worth it in my opinion.

For the Artix7 device I wrote a multi-channel component that wraps around the vendor's DDR2 interface. It features statically allocated priorities, read buffers, and memory address reservations. I could post the code if there's enough interest.

I've had trouble supporting anything beyond a low-res VGA screen (680x384) with all the shared devices accessing the memory controller. So I finally put the VGA screen in block memory (256kB) since it was going to be low res anyways, in order to improve overall system performance.

Nice work Arlet, and thanks for sharing too!

If you remember, did you find your SDRAM + video interface to be the bottleneck for F(max) in your design, or was their enough bandwidth that this was not the case. Also, what video clock rates were you running? I presume 25.175 MHz?

My experience echos yours, Rob. I also found it necessary to add additional logic to deal with bus contention which I eventually gave up on in favor of using the on-board dual-port RAM on the FPGA.