Well I went with the Spartan 2, and system voltage will be at 3.3V. The single most limiting factor on deciding on an operating voltage for this final stage, was the speed of the largest SRAM I could find. Large/Fast SRAM is top prioity for this last stage. I found 2Mx8 SRAM only in 3.3V. At 5V, the largest I found was 512Kx8. (The cost was $8 for the 512K part, and ~$40 for the 2M part. Quite a difference, but I am thinking ahead to very limited board space when it comes time to have boards prefab'd.)

Before, operating voltage was priority only because of the (incorrectly assumed on my part) limitations of my EEPROM programmer. I am now aware that it can burn a 3.3V device. This is the other reason I decided to make the whole system 3.3V. Although, this will limit the WDC65C02 to 14MHz...

Final speed of the CPU will depend on the max operating speed the Spartan 2. I am tapping the main Pulse Width 16-bit counter inside the FPGA for the CPU clock. I am shooting for a 12.5MHz CPU clock if the FPGA can run @100MHz. If it can't run that fast, I'll have to settle for 80MHz, and a 10MHz CPU. Either way, the Spartan 2 will be running 8x faster than the CPU and I think there will be alot of room for some interesting possibilities...

I am going to try some custom opcodes to address the 2Mx8 SRAM and 512Kx8 EEPROM. Instead of an LDA/STA to bank registers, 2 "unused" opcodes will be "read" into the bank flip flops using the: SYNC signal, an 8-bit magnitude comparator, and the Phase 2 Signal to control a 2-bit counter. Thanks to Dr. Jefyll for his help on his thread here: viewtopic.php?t=1556, all detailed info about my use of mod'd opcodes will be posted there.

I am currently in the process of re-inputting the schematic for the FPGA. Here within the next couple weeks, I hope to have something working.

(In hindsight, now that the system is @ 3.3V, I maybe should have used the current Spartan 3 family in 100-pin VQFP... Still, the Spartan 2 is 5V I/O tolerant. It may be useful for something in the future...)

Here is what I have assembled so far in this, the last! chapter:

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

The backordered 5.7" 640x480 TFT display is finally on it's way. It's going to change quite a bit of my current software. (I'm starting to get a feeling like I'm changing too many variables for this new build... Gonna be a challenge thats for sure!) Addressing scheme is the same as with the old unit, even though this one has more functions. Hardware windows, being one of them, if I remember correctly... Same price I paid for the now discontinued 320x240 8-bit display last year. If this is the price of progress, it is worth it.

Link for the display here: http://www.newhavendisplay.com/index.ph ... 9ekbsgp5m3

Edit:
In the previous post I stated there was only 1 family of 5V tolerant FPGA made by Xilinx. That's what I knew then, this is what I have learned now: According to this new Xilinx thread (look down to the 5th post), the original Virtex series is also 5V I/O tolerant.
http://forums.xilinx.com/t5/Spartan-Fam ... td-p/74303

Unable to find any versions available on Digi-Key no matter which version or # of pins of Virtex family ( http://www.xilinx.com/support/documenta ... /ds003.pdf)

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

Virtex 2 would probably be a nice choice for a 6502 on FPGA, since no logic level converters are needed... Although, I can't find any!

I received the new NHD 5.7" 640x480 display yesterday, so I was able to finalize socket positions and start wiring it up. Today I completed wiring: the 12V-in connector, the 5V, 3.3V, and the 2.5V regulators. The heat sinks are from old circuit boards. They may be overkill, but I prefer large safety margins. The 12V-in connector feeds the 5V regulator. The 5V reg feeds the 3.3V AND the 2.5V regulators. All tested OK...

Next step is bypass cap's and power connections to all IC's...

Like the last display unit I received from NHD, it is factory jumper selected for an 8080 style interface. The soldered jumper is easily changeable to 6800 style interface as shown here thanks to NHD: http://www.newhavendisplay.com/forum/vi ... ?f=6&t=356

Question: Should I stay with .1uF bypass cap's? I've seen the formula's saying to use bypass cap's in the nF range. I'm not comfortable with that. I can see maybe .05uF, instead of the .1uF I have been using.

A pic of what has been assembled so far:


EDIT: Grammar, spelling.

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

This is the problem with the FPGA industry as a whole. Once an FPGA becomes cheap enough to fall into amateur hands, they discontinue the architecture, we're forced to grovel for scraps. It wouldn't be so bad, though, if FPGA vendors would agree on a wire standard for programming not only current devices but future devices as well. But, no, they can't let out any "trade secrets."

This is why I support Intellasys and GreenArrays chips so much. I really hope they can bring chips to the mass market, so that we can hack with general purpose, long-lived hardware instead of the poster-children of planned obsolescence.

Yes, while slower than FPGAs, they're plenty fast enough to drive a VGA entirely in software at 640x480, if not 800x600 with tricky programming.

If capacitors were perfect and you did not have significant stray inductance, then .1µF would always be better for bypassing than .01µF. Common hobbyists' projects typically have a lot more stray inductance (mostly from lead length) than SMT production stuff though, so they'll get better high-frequency bypassing with the .01µF. In many cases, if you want to increase the capacitance, you'll do better putting a few .01's in parallel than using a .1µF. There was some discussion of that here.

You can pick up a Virtex II at digikey for about $80 for the smallest chip. Thats not bad for a Virtex - you're really looking at the wrong family; the VIIs are approaching discontinuation and are old devices. They're really intended for building high performance, low quantity, high cost equipment - think network switches and such. The more expensive ones (Up to $4000 per chip) are generally rarely found outside development boards (They're often used for CPU design).

If you want an FPGA family to use for your own designs, look at the Spartan III (or Altera's alternative). They're the volume families, built in more modern processes and cheaper to produce. Of course, they don't have 5V IO - the process nodes which support them economically simply can't support it.


Planned obsolecesence? The Virtex II family is over 10 years old. That's a very good life span for a device of this complexity. Processes get discontinued, and Xilinx aren't at liberty to choose when (no fabless company is).

Oh, and the programming information for Xilinx devices is very well documented. The open source OpenOCD JTAG system knows how to program them; as does the free ISE software.



Tell me: If I program that for a GreenArrays device, how do I move it to one by another vendor?

Because, with an FPGA, all I do is recompile it with their software. The language is standard. Heck; most of the time even the programming cables are standard (and, indeed, via OpenOCD you can use the same cable to program your FPGAs, CPLDs and ARM CPUs - and all through the same board connector)

The last I looked, I was completely unable to find documentation on the bitstream format used to program Xilinx's devices. E.g., there is no information with which I could use to enhance Icarus to support synthesis for the newer FPGAs, or to create my own completely new logic design tool.



The JTAG interface standards cover bus protocol, which of course is well documented. It's what you communicate over that bus protocol that I'm talking about.



The GA device is a matrix of Von Neumann-architecture microprocessors, so you'll need to recompile your code for the new device's microprocessors (just as you need to recompile your Verilog for new FPGAs). Then, you'll need to program the chip through a cable or embed the source in an SPI-compatible EEPROM device.

The nice thing about GA's chips is you can talk to them via either RS-232 or SPI, depending on which core you choose to boot the chip with. The bit-stream is fully documented -- you're just downloading a raw binary image of an instruction stream into a region of RAM.



SQL is standard too, and yet applications invariably find themselves vendor-locked. I've talked with the author of Icarus on the gEDA mailing lists in the past, and he'll be the first to tell you that Icarus doesn't simulate all Verilog designs out there because of tons of vendor-specific inclusions or interpretations of the "standard".

While I don't doubt things are way better than they were when I last looked, it's by no means a completely solved problem.

I can't say I know the specifics of the bitstream format; that changes per device since its really just a dump of the device's configuration RAM and therefore unstructured.


The commands for downloading bitstreams to the device are documented. As said, OpenOCD can download to Xilinx FPGAs.


Where on their website is this instruction set documented? Heck, where are the datasheets?

Where do I get a standard toolchain for the device? (In the case of an MCU, the de facto standard toolchain would undoubtedly be a C compiler & linker)



While there are deviations - as there are for all multi-vendor standards - in general it is possible to write a portable design. Most of the vendor-specific stuff is so documented, and primarily there to allow you to optimize (E.G. blockram or multiplier primitives)

You contradict yourself with respect to what I'm talking about. You first admit you don't know the bitstream format sent to the device, and that it changes per device. Then you say, "But, OpenOCD can program it! Use that instead!" You're completely missing my point.

The dump, of course, is not unstructured (it's actually rigidly structured, which is why it has to change with every chip design), but it is instead opaque. The details are not public -- only Xilinx software knows how to generate the bitstream for Xilinx (supported) parts. That is my beef with the FPGA industry.



They're a new company started by the developers behind the Intellasys product-line. See http://www.intellasys.net/index.php?opt ... &Itemid=75 .

The reason GA exists is because of severe IP rights fall-out between the venture capital firm backing Intellasys and the (now former) senior management of Intellasys. Lots of lawsuits. Lots of hard feelings. And a VERY REAL possibility that this technology will NEVER see the light of day.

I really, really, really hope it doesn't come to that. And, you shouldn't either. Lots of companies like BMW and Sony were lining up to grab ahold of these chips, and very cheap eval kits were on the horizon just before this all started to happen.

At any rate, I have Intellasys chips in my possession. I've coded for them. VentureForth is a somewhat specialized version of Forth Inc's SwiftForth pre-programmed to work with Intellasys' parts (with full source included, I might add, though it's not technically open source).



You cannot use C to write software for these cores, because they are 18-bit stack architecture cores with only 64 words of RAM. You'll need to learn to use Forth.

But, if you think you can pull it off, the details of programming the chip are included in the online documentation. Have at it. They don't care, and even encourage it.



If you're really in the market (and not a hobbyist), you don't choose Xilinx and then stick exclusively with generic Verilog. If you're going to differentiate your products on the market, you're going to use everything at your disposal to do so, which directly translates to, your products will become hard-dependent on vendor-specific extensions.

I agree with OwenS, and I too am using Xilinx's software with JTAG, which is an excellent piece of software to enable Xilinx IC's, from version 10.1 to present (I've not tried version 12 yet). Along with their forums, their IC's are quickly and easily put into action...

The only negative I am learning about the newer families of Xilinx FPGA, is the BGA package. The Virtex and Virtex II families are still available at DigiKey as OwenS pointed out, but only in BGA style package. Trying to negate the hobbyist?

Bake at 240F for 40Sec? Sounds doable... Maybe Later.

Wiring up the new build...

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

Its probably possible to write a C compiler for it then - but it would definitely not be ideal. Especially when, by what I understand (Sorry - their architecture is somewhat confusing me) each core only has room for 192 instructions (or 230?).

The big question is if they can get any of these chips into volume production before XMOS - Who have been shipping in volume for a couple of years now - completely conquer the massively parallel market.

(It would be interesting to do a power comparison of the two - one XCore MIPS is undoubtedly more useful (Single cycle multipliers and multicycle dividers will do that), and the XCs have significantly more RAM per core - but the GA/Intellasys chips definitely have more of them)



No - you'll develop with generic Verilog, then use the Xilinx/Altera/Actel primitives to optimize. At least, thats what you'll do if you're smart, anyway - or if your plan is to eventually move to an ASIC.

Companies like ARM and Freescale have no trouble shipping cores which can be synthesized on all (sufficiently big) FPGAs and ASIC processes. Its not a problem.

A week ago I said I was wiring up the new build. Wrong! I was too gung-ho. The 100-pin and 54-pin BGA-adapter sockets for the Spartan 2 FPGA (100-pin VQFP) and 2Mx8 (54-pin TSOP II), are intimidating. I wanted to be sure the design/placement/wiring was correct, and I found errors. When I do finally start wiring next week (no errors found today), it will only be when no errors are found, because eliminating a wiring problem at this point is a huge variable eliminated.

The past week I've spent double checking pin assignments and revising/finalizing the schematic. The schematic for the FPGA, FPGA PROM, CPU, SRAM, and EEPROM, is actually simpler than my earlier versions, because now all the intricate stuff is inside the FPGA...

I've used Xilinx CPLDs in the last chapter of this project with no problem. However, Xilinx FPGAs seems to be a bit different. There is now a need for a PROM to bootup the FPGA on "stand-alone" power-on. (Not an issue when using IMPACT, since power is still present after programming and definately not an issue when programming their CPLD's because they are EEPLDs). There seems to be a few multiplexed pins, some are dedicated, (I chose to keep all the PROM interface pins Not-Connected) so the pins for serial "PROM" are truly dedicated, thus eliminating 1 more variable...



I dislike this strategy as well. What about future generations of hobbyists?! Sounds like their accounting dep't is trying to force huge lot purchases, out of fear of discontinuance. Too bad. Still a nice tool to learn from right now... One other point though: Their CPLD's and Spartan 2's are still in production, so at least they have an ear towards the demand side and not trying to force their new super complicated product line on everyone. Their CPLDs are an excellent learning tool.

***One can now see why many TTL IC's are being forced into obscelence. Now the full circle can be seen: Obsolete the original TTL with the CPLD, then obsolete the CPLD, and what do you have left? Just the kings of the class, no experimenters, no hobbyists, just the privied. ***



So what you're saying is to bypass an IC with, for example, 10 VCC pins with .01uF, so they add up to close .1uF?

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

I'm going further than that, saying that you'll get better (lower-impedance) bypassing from say three .01's strategically placed than you would from a single optimally-placed .1µF. The inductance of the connections in series with the capacitors produces a resonance where the capacitive and inductive reactances cancel each other out and the remaining impedance is only the equivalent series resistance of the capacitor and the traces and leads that connect it. Above this resonance frequency, the impedance becomes inductive and climbs rapidly. That resonant frequency, in some hobbyists' construction with .1µF capacitors, may even be below 10MHz, which is really poor, and they would get better bypassing above that frequency by decreasing the capacitance. (That's only a small part of good bypassing practice though. If you want to get more technical, one article on the subject is at http://www.avx.com/docs/techinfo/mlcbypas.pdf .)

Xilinx still make XC95s and Spartan 1s with no declared end of production. The Spartan 1s have now been in production for an aeon compared to most components.

The Virtexes on the other hand do have a short life - because they're not supposed to be long term parts. They're for high price low quantity devices - the kind of things which need to be redesigned every few years to stay current anyway.

For hobbyist purposes, the Spartan families are the way to go - and the new chips (Spartan 6) are still coming out in QFPs.

I was not aware of this. I saw only BGA type packages. What distributor are you looking at?

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