65Org16 Assembler on custom Xilinx Spartan 6 FPGA Hardware

[ElEctric_EyE]

ElEctric_EyE wrote:

...I'm going to run a project through ISE and experiment with the constraints file in order to see if it generates any errors...

In the constraints file of the last Spartan 6 project I did, I changed just a few pins of the 16-bit RGB in bus to 2.5V from 3.3V (I did use 3.3V LVCMOS, not 3.3V LVTTL) and it just gave warnings regarding delays. So I would expect this, at least no errors. Sorry, my brain is thawing!

Another experiment where I changed the entire RGB In databus, including the H/VSync and Pixel clocks, to LVCMOS 2.5V, while everything else was LVCMOS 3.3V, it passes with no warnings!

Good to go. I must now just figure out these multi-function pins. Which to use, which not to use.

[GaBuZoMeu]

/A21 isn't mentioned in the "General Layout" ?

[ElEctric_EyE]

GaBuZoMeu wrote:

/A21 isn't mentioned in the "General Layout" ?

Sorry, it's 'implied'. Those SyncRAMs have 2 active high enables and 1 active low enable per IC. In the Block Diagram I have a grey line designating/implying 2x 2Mx18 SyncRAMs. Sorry for that laziness on my part

[GaBuZoMeu]

Well, then this looks fine

The only remaining question is, whether you can use a keyboard attached to the MCP2200 or a PC only. I think a keyboard requires a "USB master" (what a PC usually is) and to me the MCP appears to be a slave only device.


Regards,
Arne

[ElEctric_EyE]

GaBuZoMeu wrote:

Well, then this looks fine

The only remaining question is, whether you can use a keyboard attached to the MCP2200 or a PC only. I think a keyboard requires a "USB master" (what a PC usually is) and to me the MCP appears to be a slave only device.


Regards,
Arne

The MCP2200 will spit out Rx data from a PC or a keyboard input via USB connection. I never did try to send commands to the keyboard or PC though. Hmmm, that may save me another pin right there. No need for Tx in my case...

[Chromatix]

Many "modern CMOS" devices can indeed operate at 1.8V, but may be somewhat slower there than at higher voltages they also support. Check for this in their datasheets.

[ElEctric_EyE]

Chromatix wrote:

Many "modern CMOS" devices can indeed operate at 1.8V, but may be somewhat slower there than at higher voltages they also support. Check for this in their datasheets.

I've been checking the datasheets for min op volts, believe me. It's going to be interesting... I've never run so many parts at such a low voltage. I'm thinking the bypass cap's for these devices may be in the .01uF or even .001uF range, instead of the more oft found .1uF.

Time for parts update tomorrow.

Things are always changing. I can no longer find a 300MHz HCMOS can oscillator that I used in my old project. It's mostly differential LVDS stuff. While LVDS is compatible with Xilinx input spec's, it requires 2 pins per clock input. So that's another reason I went with a lower frequency 100MHz LVCMOS. The other reason being 1.8V output.
However, I was able to find a 250MHz can oscillator at 3.3V output in HCMOS, which I'm probably going to go with, now that I'm not freaking out about the different voltage IO capability of the Spartan 6.

[ElEctric_EyE]

OK, I've finally found info regarding the voltage supplies needed for the Spartan 6. It's just a bit complicated when using multiple I/O voltages but not so much when you think that we're dealing with CMOS here.

I believe everything should work fine on the Master. I think I'm going with a 148.5MHz 1.8V CMOS SMD oscillator. That way I can save a PLL inside the FPGA and also abide by the 1.8V standard without worries, especially since it's the main clock. The only other pin to worry about, on the Master S6, is the 3.3V input from the USB to UART Rx pin. I've deleted the Tx pin. According to Table 1.5 Xilinx UG381 on Pg. 39, which I've posted below, inputs can be higher than the voltage present on the VCCO pins.

So, the VCCINT pins will be 1.2V, the VCCAUX pins will be 3.3V and the VCCO pins will be 1.8V on both S6's. So this leaves an issue with the Slave S6 and the SD Card interface since that is 3.3V IO. Haven't figured that one out yet, except maybe some simple voltage translators on the outputs of the Slave S6?

The SyncRAMs are current hogs at almost 300mA per IC. I've got my eye on a Analog Devices 1.8V 2A regulator, in a nice small 3mmx3mm WDFN package, that should take care of them. Then multiple/individual 1A reg's, in SOT223 from the MCP1826 Family, that will power the FLASH, HDMI and S6's. They're all nice and small.

I've started a parts list in the head post on this thread although it's already old as I'm typing this. Some parts have gone up in price, especially Xilinx FPGA PROMs. They were $4US 4 years ago! I might experiment using cheaper SPI FLASH.

Back to the datasheets! There's so many pages per manual. Took me over an hour to find that one table.

EDIT (9/5/2018): VCCAUX is 3.3V not 2.5V. Not a big deal...

[ElEctric_EyE]

3 more developments regarding the block diagram evolution:

1) MUXing the JTAG programming of the Master/Slave Spartan6 PROMs from the PC, ISE14.7. Done this before, but this time will be manually switched.
2) MCP2200 USB to UART is Rx only and has it's own 3.3V 12MHz Osc.
3) The 1.8V CMOS Master CLK Oscillator is programmable from 10-160MHz but boots up @148.5MHz.

[ElEctric_EyE]

The SD Card part is back in business with some really nice looking logic level translators made by TI.
Lucky for me the 1.8V <-> 3.3V has the highest throughput @500Mb/sec. Not sure how fast I'll need yet, but the faster the better. I'll be aiming for the SPI bus mode for simplicity.

[ElEctric_EyE]

SO, 1 issue from the beginning on this S6 144-pin QFP package was the lack of IO pins. I knew this from years ago. The datasheet says 102 User IO pins for this package. That's only if one goes out of their way to hold certain multi-function pins at certain logic levels during programming from external CPU's or something. Well my CPU is inside the S6, so after much reading and many, many checks I've got 98 pins free on the Master S6 which is going to limit the Communication port to the Slave. I was aiming for 22 pins as it could fit a full 4M address. But this might not be a big deal after all...

For example, in order for the line state machine inside the slave S6 to start plotting it will need a 22 bit address and a 16 bit RGB data for the start point. The same for the end point. So, if there were enough pins, the comm port would be 38 bits wide and you could get both coordinates over, with the data, in 2 cycles, ideally. So I was initially aiming for 22 pins for a full address coordinate transfer, but then would need to transfer 16 bits of data, 6 bits wold be unused during the data portion. My goal of a super wide comm port was erroneous...

SO figure 38 bits total, (22 address + 16 data)/2 = 19 bits. 4 cycles to send 2 sets of data+address, in some divided fashion. This is 19 bits compared to 22 bits, saves me 3 more IO pins. This will fit safely into the design!

SPI FLASH to Program the FPGAs next. Might be a few days...

[MichaelM]

EEyE:

Perhaps you might consider a low pin count bus like Intel's LPC bus for inspiration. Graphics transactions tend to be characterized as sequences of data starting from an initial address and proceeding linearly. Transmitting the address for each data is somewhat redundant. Like the command / address cycle of an SPI Flash/RAM, the target of your read/write operations can capture the initial address and increment the address internally as the data is read from / written to your graphics slave device.

[ElEctric_EyE]

MichaelM wrote:

EEyE:

Perhaps you might consider a low pin count bus like Intel's LPC bus for inspiration. Graphics transactions tend to be characterized as sequences of data starting from an initial address and proceeding linearly. Transmitting the address for each data is somewhat redundant. Like the command / address cycle of an SPI Flash/RAM, the target of your read/write operations can capture the initial address and increment the address internally as the data is read from / written to your graphics slave device.

AH I see your point. The data is redundant. I think the key is going to be in the state machines and how to send the address and data efficiently. Speed is always key in graphics.
Considering this in a graphics type system here, where the CPU is not technically 'sharing' video memory but rather sending commands to a hardware plotter it's sort of a different beast. I should make that clear here. Not every pixel is plotted linearly like when doing characters, sprites and such. Lines or circles require jumping around the map. However, plotting characters obviously will be needed... But I must resist the temptation to get into the graphics side of this in too much detail else the main goal might be lost. I just need to design the possibility into the hardware.

I think the hardware design idea is almost solidified, there are the final 19 pins to be used for the Comm port. Heck, it could be 18 data and a R/W line. The possibilities are there. I just need to solidify the hardware side which I believe is very close. I just have to recheck, recheck, recheck,.....

[ElEctric_EyE]

I would like to posit an idea I've been thinking about for the hardware layout of the SyncRAMs and see what you guys think. Since I'm not an EE, I don't know all of the ramifications...
I was thinking of stacking the SyncRAMs and just bending the CS/CS pins out of the way. Not that I'm lazy, but this would save on different trace lengths for each SyncRAM.

[MichaelM]

EEyE:

I would be concerned about signal integrity issues as you push the data rate. To construct a board needing two RAMs in a similar situation, I opted to place the devices over each other on the front and back of the board. The connections for the majority of the pins were done through the vias that were a natural consequence of the component placements. Only a small number of control signals, like the nCS lines you mention, were routed independently with and eye toward signal integrity. I was using standard SRAMs, and I am not sure, not having looked up your SyncRAMs, whether they truly support random access like a standard SRAM.

Although your concept is doable, I would be concerned as to the signal stub lengths if you end up including AC impedance terminations on the busses from your FPGAs to these devices. Since most of us don't have access to signal integrity modelling and simulation SW, it may be that you'll just have to take your chances. However, given the expense of your components, the PCBs, and the time it will take you to assemble the SyncRAMs in the manner you describe, I'd wuss out and use the approach I described. You've demonstrated mastery of assembling SMT/BGA components on your boards in the past, so my concerns are likely to be unfounded.