65Org16 Assembler on custom Xilinx Spartan 6 FPGA Hardware

[jds]

It is also possible to make use of the extra space in the SPI flash. Once the FPGA has read the flash it can be accessed using the SPI bus from the FPGA. I don’t know if you need any flas storage, but if you do, you’ll have some available.

Initial programming can be done by modifying the Xilinx programming file to add the extra data on the end of the file that ISE generates.

[ElEctric_EyE]

MichaelM wrote:

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.

Yes, I use Verilog too where can I check out your SPI cores?

jds wrote:

It is also possible to make use of the extra space in the SPI flash. Once the FPGA has read the flash it can be accessed using the SPI bus from the FPGA. I don’t know if you need any flas storage, but if you do, you’ll have some available.

Initial programming can be done by modifying the Xilinx programming file to add the extra data on the end of the file that ISE generates.

Interesting, I was thinking about programming the other 4 or so Mb with different character fonts. I never thought about adding it to the programming file. I'll have to experiment with that, thanks for the heads up!

[MichaelM]

SPIxIF
LUT-based FIFO

Either soft-core project provides an application of these two components as a buffered SPI Master: M65C02A_SPIxIF or M16C5x_SPI.

There are simple test benches for the various components and the integrated modules. (If not in the same directory as the modules, then look in the Sim directory of the project.) Also, I use memory initialization files, found in the directories for the components. Use these as is, or edit them as needed, to ensure that the simulations work correctly. By default, the memories, whether block RAM or LUT-based, are initialized by the FPGA during the boot process to 0. However, this does not apply to the behavioral simulation, so explicit initialization of the memories from which the FIFOs are constructed is required or the simulator will indicate "unknown" logic states.

[ElEctric_EyE]

Thanks! I've not checked out the code or comments yet, but what speed do you run your SPI FLASH or what's the fastest one could expect? Up the the IC spec'd max?

Added an updated block diagram to the head post. Hopefully the last, but...

[MichaelM]

Standalone speed ratings for simple components such as SPI I/Fs can be misleading.

When targeting a -4 Spartan 3A FPGA, the interface in the M16C5x project (a 60 MHz single cycle PIC16C5x soft core) is mapped, placed and routed (and used in an FPGA board) using a 100 MHz timing constraint. Attempting to fit that core into an 6SLX4-3 FPGA also uses the same timing constraint.

The UCF file for that project indicates that I attempted a 166.667 MHz timing constraint for the interface, but I don't recall what FPGA, possibly the A70T, or speed grade of the FPGA was the target. If a timing constraint is not achievable (under some condition or for a specific FPGA), I generally don't leave it in the UCF file.

[ElEctric_EyE]

Michael thanks again, I shall have to revisit when I get to this part of development!

I've experimented with KiCad and placed all IC's except for the SPI FLASHs for FPGA config. The footprint for that IC wasn't included in the library.

I'm estimating a board size of about 3"Wx5"H. Looking at Eurocircuits again, like I did years ago. Their prices are not too bad. For a single 3"x5" 8 layer board it's under $200US for a 7 day production time. Silkscreen on bottom is free. And they have the option to add top and/or bottom stencils. Not sure how much they are, they're not absolutely necessary if they turn out to be too expensive...

Looking at 8 layers because it gives so much more freedom to route and have a noise free environment as well. At this board size, going from 4 to 6 layers added $40, going from 6 to 8 added just another $30. This should be a really nice compact design!

[ElEctric_EyE]

Things still in a 'state of flux'. Parts changing, layers changing. But things are definitely solidifying...

Since I decided to go for 8 layers, , multiple 1.8V 1A VREGs will be used instead of a 2A VREG that powers all SyncRAMs. Now there's 1 for the top pair of SynRAMS, 1 for the bottom pair, 1 for the FPGAs/config Flashs/256Mb Flash, and another for the HDMI transmitter.

Also, in KiCad I've learned how to spec a board outline for the fab house. Also how to cut up a power plane, so I can have different volts per section of a plane. Would hate wasting entire planes for the FPGA 1.2V and 2.5V as no other IC uses those volts.

Back to work, rereading UG393 before starting to lay down traces...

EDIT: Removed hurricane Florence reference. Hope everyone is OK. It missed us.

Cheers!

[MichaelM]

EEyE:

If you feed power planes with your voltage regulators, I would recommend keeping the planes powered by each regulator separate from the others. Since it appears that you can construct different power distribution areas on a layer, then even if you place the power distribution for the SynchRAMs on the same layer, I would construct independent power distribution elements for each. You don't want the voltage regulators fighting each other to keep their outputs at the levels each is independently sensing. Furthermore, since you plan on having separate power regulators for the SynchRAMs, I would also recommend that the power for the logic from the FPGA driving those devices is derived from the regulator powering the devices that they are interfaced to.

You may have already come to the same conclusions. If so, please disregard.

Good to hear that you and yours have come through the storm in reasonable shape. Certainly hope that the after effects of the storm will be rapidly corrected.

[ElEctric_EyE]

MichaelM wrote:

...since you plan on having separate power regulators for the SynchRAMs, I would also recommend that the power for the logic from the FPGA driving those devices is derived from the regulator powering the devices that they are interfaced to...

This is definitely great advice! Now, each 1A 1.8VREG will power 2 SyncRAMs and FPGA. That is approaching 1A quickly but the MCP1826's should be able to handle it.
The Ground plane is the only common plane amongst all VREGs. This plane will be solid. Maybe multiple ground planes closest to the top and bottom signal layers with inner power/signal layers might provide a hidden benefit of capacitance?

[ElEctric_EyE]

Sometimes I'm so thick. I'll just use a 1.8V 3A regulator to power everything except the HDMI Transmitter. I think that should have it's own low noise 1.8V regulator.

[jds]

Another way you could save some FPGA pins, at the expense of a bit more FPGA code, is to not use the HDMI transmitter and directly connect the HDMI connector to the FPGA. This requires 9 FPGA pins, it looks like you are using a 16-bit RGB bus plus some other control pins, so this could save a few pins. It also makes the board design simpler.

For an example circuit you can look at this schematic:

http://www.saanlima.com/download/pipist ... ematic.pdf

but a lot of the spartan-6 boards with HDMI have a similar design.

This may not be suitable if you want Full HD, it can be done and it does work, but the jitter in the transmitter PLL means that it's not up to HDMI specification. All the details can be found at http://hamsterworks.co.nz/mediawiki/ind ... an_6_1080p.

[ElEctric_EyE]

jds wrote:

Another way you could save some FPGA pins, at the expense of a bit more FPGA code, is to not use the HDMI transmitter and directly connect the HDMI connector to the FPGA. This requires 9 FPGA pins, it looks like you are using a 16-bit RGB bus plus some other control pins, so this could save a few pins. It also makes the board design simpler.

For an example circuit you can look at this schematic:

http://www.saanlima.com/download/pipist ... ematic.pdf

but a lot of the spartan-6 boards with HDMI have a similar design.

This may not be suitable if you want Full HD, it can be done and it does work, but the jitter in the transmitter PLL means that it's not up to HDMI specification. All the details can be found at http://hamsterworks.co.nz/mediawiki/ind ... an_6_1080p.

Wow that looks a little complicated, but that's super cool he was able to push a Spartan 6 like that without any external HW! BTW, I've gotten my pin contention issue solved, 19 pins for the FPGA Master/Slave Comm port should be enough for decent high speed while still using the HDMI transmitter...

I've finally gotten around to some PCB layout after a couple days of experimentation.

First starting out with GND & power connections and bypass cap's on the master Spartan 6, although not utilizing all 8 layers yet. The VCCO 1.8V layer spans the entire board as does the GND layer. Regarding the 'chopped' layers involving the S6: VCCAUX (2.5V) is a blue area on layer 6 and VCCINT (1.2V) is a green area on layer 7 right under the S6, Blue layer sort of difficult to see.

So far that's all that is going on on those 2 layers, just right under that FPGA. It'll get more complex after doing the same to the slave S6 and then joining those areas on both layers. I'll try not to have too many vias poking holes through that master slave power plane(s) connection.

[ElEctric_EyE]

Finished both FPGA powers/GNDs and bypass caps. At which point I could place them as close together as possible. Worked out nice. Now time to do the same for the SyncRAMs. These will be a special challenge as these ICs will be mounted on the top and bottom on the board. So there's no possibility to place the bypass caps on the opposite side of the board underneath the IC.

Here's what it's starting to look like on the top and bottom SyncRAMs. Goal was to make no shared power or ground vias. That's a big no-no. Goal achieved.

[ElEctric_EyE]

What I have to consider now, simultaneously, is bringing out all the address and data lines from both top and bottom SyncRAMs into common vias that go to the FPGA.

[ElEctric_EyE]

Finished all bypass cap placement for all 4 SyncRams and both FPGAs. Here's a glimpse of the full board from the top: