I think you're correct. I'll take your advice and mount them on both sides of the board.

I think it's time to finally start the board design. Definitely going for 4 layers, will just have to see the size of it. It will use a single 5V power supply between 3A - 5A. Instead of posting pics on the progress of the board design, I'll just post a final version that goes to EPCB for production. ETA on that is going to be about 2-4 months as I have to learn the Plus version the the EPCB layout software. I do intend to see if their software can now do tented vias as they claim it does for a future BGA designs. I'll just do a small experiment on the corner of the board.
I do intend to post schematics of the FPGA PROM section with the MUX or maybe come up with a better idea. Still have to reread that datasheet...

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

Posting schematics & placement would be fine.

I am curious: why 5V ? So far I see 3V3 and 1V8 (and perhaps somewhere 2V5). Only USB has 5V but that is delivered by the PC.

An idea, that just came to my mind: do you have at least one pin for signaling some FPGA internal state that you can use for triggering a scope if things doesn't work as intended?

The VRegs have a max of 6V and 6.5V input. 1 single 5V will power everything. It's an easy voltage to get off an old PC power supply and filter it as necessary

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

I think I'm going with KiCad to do the PCB layout. I remember year ago I tried it and liked it but the layout portion of the software was linked to the schematic portion in order to help the user not make erroneous connections, which bothered me. With a schematic with so many pins, a ratsnest is total frustration. NOW, they have a newer version which you can disallow the Design Rule Check and starte with the PCB layout and just start routing. Progress is a beautiful thing! I'll probably donate some $. It's really powerful and most of all intuitive.

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

From the custom PCB page of the 6502 primer:

Incidentally, I still do my schematics by hand, since there are things about all of the schematic CADs that I don't like. At my last job, I got very proficient at OrCAD for schematic capture, but it was terrible. Now I go straight from hand-drawn schematics to PCB CAD, without using netlists & rat's nesting, etc.. And using this method of checking, I don't get any errors either.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Can't beat the hand to paper. For me, it really helps me to remember things MUCH clearer. The block diag's started with pen to graph paper...

Well, I don't want to make this a mega-thread like some of my other projects, it's already 4 pages just for the block diagram! So I guess I'll just post an initial parts placement pic with all IC's and connectors. Then a final, before I send it off to get produced. Any objections?

BTW, no lost project data this time! I'm working from a 500GB NVMe on my desktop. Daily back-ups on RAID 5 HDD and a DVD burner.

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

I thought I might back up a few steps and share a little bit how I came to 98 I/O pins that are free to use without contention. I modified Fig. 3.1 of UG385 Pg. 274, in order to show how some of the "multi-function" pins actually must be tied to a logic level for my case without an external CPU controlling pins. Most of the pins are the ones dedicated to the FPGA PROM.

Understanding UG385 is critical to success. I checked this data against past designs, especially the PVB project. The only discrepancy I found was VCCAUX in that project was 2.5V, not 3.3V. It shouldn't be too difficult to swap out a 2.5V to 3.3V VREG once the board is complete just in case.... I know what I did back then: I looked at multiple design schematics which were available online, from Digilent etc., and considered if my design was similar enough to use the settings they used.

EDIT: I found it! VCCAUX must be 2.5V if VCCO is 1.8V according to UG380, Pg.43 Note 16.

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

I'm working on Configuring both of the FPGA's so I'm reading alot of UG380. I think I've found a solution to those expensive XCF04 'PROMs' by using the SPI Config interface. If I understand the datasheet correctly, ISE goes about programming the SPI FLASH 'indirectly', i.e. it programs the FPGA and then the FPGA programs the data to the FLASH. Whereas, when I've used the Xilinx XCF PROMs in the past, ISE would see the FPGA and the PROM and you could program either one.

Now which flash to choose. According to this link Xilinx has just a couple recommendations when VCCO is 1.8V, like in my case. I have to use an 8Mb device, when the Spartan 6 LX9 only takes 2.7Mb. I'm all new to this but I don't think the 1 FLASH can program both FPGAs? I have to do more research...
Updating parts list.

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

I think that, with the advent of the multi-boot programming feature, using commodity SPI Flash devices, daisy-chain programming of a chain of FPGAs from one SPI Flash on the lead FPGA is probably out. One thing to keep in mind, the Xilinx tools load an SPI Flash programmer into the FPGA connected to an SPI Flash device. That programmer is generally very persnickety about the manufacturer's ID and device type. Since you will not likely want to write your own SPI Flash device programmer application to download into the FPGA using JTAG, then I recommend that you stick to the devices that Xilinx recommends regardless of any particular biases you may have for one Flash manufacturer or another, or one size versus another. If Xilinx does not list the device you select, then there is a very high probability that their programmer will not program the device.

_________________
Michael A.

I thought the daisy chain feature might not work using 1 SPI FLASH. I guess we're lucky just to even have the Spartan 6 around for so long. The support has died... So I'll try a reasonable method of MUXing 2 FPGAs with their individual SPI FLASHs to the JTAG IF.

I did very carefully choose the SPI FLASH IC according the the link I posted above. I found it interesting that the Virtex device could use a 4Mb SPI FLASH, but the Spartan6 couldn't. Xilinx recommends the 8Mb SPI FLASH for the Spartan 6 @1.8V VCCO. So that's the SPI FLASH I chose.
Here's a pic:

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

If you chose to use Slave or Master Serial for your lead FPGA, then the support for programming a chain of FPGAs using this mode from one is still available. The problem with the SPI Flash as the programming source lies in the fact that the FPGA has to transmit a read command, a 24-32 bit starting address, and then a stream of values to the device in order to have the device output its contents. This is unlike the Master/Slave serial modes supported by the XCF0x parts which produce/consume CCLK, respectively, as the only control signal following reset.

I get the impression that Xilinx, as well as the other FPGA vendors, are rapidly increasing the size of their devices faster than they can get compatible Flash devices developed in-house. Their design resources are better spent on the FPGAs instead of continuing to design new generations of Flash programming devices. Commercial demand for Flash devices of ever increasing capacities is rapidly driving the cost of these devices into a price range that the FPGA vendors cannot match. Instead, Xilinx is taking advantage of the decreasing price of the SPI Flash devices to reduce their specific costs and those of their customers.

_________________
Michael A.

Thanks so much for your in-depth explanation. For highest chance of initial success, would you recommend a JTAG daisy chain of FPGA using Xilinx XCF series PROMs? They are expensive, but even more offensive is their large footprint for such a basic function but I'm willing to do what's necessary for an early successful programming. Thanks!

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

EEyE:

I think that you should use SPI Flash devices on each of your FPGAs, and hook your FPGAs in a standard JTAG daisy-chain. I haven't priced the minimum-sized devices needed for your Spartan 6 LX9 FPGAs, but I would predict that the cost of two SPI Flash devices is less than one XCFxx device that is large enough to program two LX9s. I've been switching all of my projects to use SPI Flash devices instead of the XCFxx devices. They are cheaper and have more sources of supply; that's the primary driving factor for me switching the SPI Flash interface.

The chance of initial success is pretty high with the SPI Flash devices. I've not had any trouble getting success on the first try with them when I use a device listed by Xilinx. On ocassion I've had to use a device not listed, and I've been able to coerce the Xilinx tools to support it by making sure that the device I used had the same (programming) organization as one of the recommended devices. I don't recommend this option as it is hit or miss. If you stick with the devices in the table you inserted in your post above, I don't think there will be any risk to your project's initial success: just make sure that you have set the programming interface options correctly as indicated in the Spartan 6 configuration guide.

_________________
Michael A.

I will try it out, thanks alot for your help!

I was over in the software section and heard talk of a hardware SD Card controller that had built in Fat32 interface built into a CH376 IC. It's an obsolete part, I don't know why because it looks really useful, but I ordered a lot of 5 CH376T in 20-pin SSOP-20 for cheap.
I plan to use this in between the slave S6 and the micro-SD slot, using the SPI interface so no pins lost or gained. Will be running this IC @3.3V so 3 volt level translators will be used.

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

EEyE:

Glad to help in any way. Looking forward to continuing to read about your progress on this project.

There are plenty of open source SPI interfaces available. I released a buffered interface (LGPL license) for the M65C02/M65C02A and M16C5x projects in Verilog, which if I remember correctly is the HDL that you were using. You're certainly welcome to use those for your SPI interface requirements. You should be able to easily modify it to fit your 65Org16 processor core. The interface is buffered with FIFOs to make it easier to send/receive data to/from SPI devices like SPI Flash devices.

_________________
Michael A.