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

Xilinx' family reference manual. Admittedly, its only the bottom two devices.

I do see the original Spartan XCS series still for sale, only the 3-3.6v XL versions.

Been slow here the past couple weeks as far as wiring up my project. Had to wait for my next paycheck to order .01uF bypass caps, also family is on vacation this week...

I ordered 4 1F (1 Farad) 3.6v cap's, some ultra high output LED modules (Diamond Dragon 455nm, 1.5A) to load the cap's with, and more pertinent to this thread, 2 miniature joysticks. 1 of them will be the first input controller device along side 2 ADC0820's which I'd previously ordered. These run at 5v, so it'll be a nice 3.3v compatibility test with the 5v I/O tolerant Spartan 2.

The miniature joysticks are pretty neat looking: http://www.ctscorp.com/components/Datasheets/254.pdf

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

Got the order today. The joysticks are ultra miniature. 4 of them side by side, could fit within the circumference of a 1/2 dollar no problem, I thought they would be abit larger... The "Ultra-caps" take some time to charge, but are quicker than rechargeable batteries. After a charge @3.3V from my power supply after 15 min's, they have some steady power @ around 2.5V with 2 diamond dragons in parallel (figure a +2A draw initially, I need to bring home my ammeter). Man, these things are bright!

I started wire wrapping all the power connections today and got into an issue. Recall that all devices, except the 2 ADC's (5V) and the FPGA core voltage(2.5V), are intended to run at 3.3V. Well, when I got to the 1/2 size 80MHz oscillator, I began to remember the waveforms I saw and that the peak to peak voltage at 80MHz from a 5V supply was way under 5V. So I hooked up 5V temp power to the oscillator and remeasured the peak voltage today. It measured close to 2.5V peak to peak...

So I am keeping the 5V Oscillator, with no intent to wire up a 3.3V one.

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

Finished wiring it up yesterday. What a breeze! Took me about 7 hours. Fired it up, no smoke or heat, heh . ISE rec'd the Spartan 2 and successfully programmed it. Stage 1 complete!

Stage 2, which I'm working on now, forces all the upper banking addresses low. So I have to temp remove all the opcode detecting hardware (not tested yet). Also, I have abit of reworking to do softwarewise, because the last iteration used an 8K EEPROM for the software, and a separate 512K EEPROM for character fonts, strings, etc.. This version uses 1 512K EEPROM for everything. Not to mention the Display is a little different...

I must say working with FPGA's/CPLD's is very enjoyable and rewarding. All one must have is a general idea of what to accomplish. Heck, looking back, using a 144-pin or 208-pin FPGA would allow you to hook up all the 6502's outputs and inputs, throw in a "few" 2Mx8 SRAM's an EEPROM, and you could have a system you could develop without having to rewire a thing!

The 2M SRAM address decoding is done in such away that when $0000-$3FFF is on the address bus, the SRAM sees all zero's on A14-A20. When $C000-$FFFF is present, A14-A20 are all one's. The SRAM does not see the SRAM Bank register in these cases. This preserves zero page, and a good chunk of RAM for registers etc., and the OS/interrupt/reset vectors. Here are my memory maps:

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

Nice graphics. They are so clear even a big dumb dinosaur can understand them.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Been doing alot of reading recently. My last statement about this stuff being easy... Scratch that. I'm getting the feeling FPGA's are a whole other beast. Although, i'm not quite ready to give up on the Spartan II yet. The version I'm using has the potential to have 512bx8 SRAM embedded inside, which will be my last attempt, before I tuck tail and head back to CPLD's.
I'm having problems with what I think is buggy 10.1 ISE software. "think" being the keyword. Repeatability is not consistent... I blame myself for not being more knowledgeable about FPGA's, so I've taken up some reading. Compared to Xilinx' CPLD's, FPGA's can fit much much more in an identical pin package, I'm sure more care has to be taken to follow stricter rules...

Anyway, during my research I came across a subject others have brought up, and I remembered this topic:



These links may help. At the very least they'll give you clues how to program FPGA's without ISE software.

The poster wanted to program a Spartan 3 FPGA with a PIC32:
http://forums.xilinx.com/t5/Spartan-Fam ... /m-p/36815 .
In the reply, an appnote was given for the general hookup:
http://www.xilinx.com/support/documenta ... app502.pdf

The Spartan II Family FPGA Data Sheet on page 15 talks about "Bit Sequence" & BSDL:
http://www.xilinx.com/support/documenta ... /ds001.pdf

http://www.xilinx.com/isp/bsdl/bsdl.htm

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

I hit a wall, so I am taking a temporary time-out to regroup and then attack from a different position. Tomorrow, I test. I suspect the display has issues... I could be wrong, we shall see....

Also, the main 80MHz oscillator I was powering @5V. According to the datasheet ( http://www.ecsxtal.com/store/pdf/ecs_2200.pdf ) it is capable of running at an optional 3.3V. I don't think this is an issue though as the Spartan II is auto-configured for LVTTL and is 5V input compatible.

Using schematic entry on ISE10.1 to program the Spartan II, has been a challenge. I'll leave it at that. I make progress now by saving files. Files made from scratch, and if they succeed I save them in the next "Chapter" on another computer... I am up to a chapter now that successfully manipulates /6502Reset, Phase 2 (fast, and slow), & EEPROM/SRAM /CS's & /OE's. I am also getting an active low signal to the display from the FPGA, still nothing is happening to init the display. I have been regretfully reduced to starting from scratch at this point. (This is a 1 step back, 2 step forward point...)

So during my time-out, I've been re-looking at some Maxim IC's for generating square wave frequencies for the WDC65C02 and the 16-bit pulse width counters. I say "re-looking" because I brought it up last year on page 3 of this thread, and I've learned alot thanks to this site, and now feel qualified enough to make a "re-educated" choice: The 1 that stands out is the Maxim DS1085L: ( http://www.maxim-ic.com/datasheet/index.mvp/id/3495 ). 8-pin SOIC, 3.3V device: 2 outputs, 1 from 4MHz to 66MHz (good for CPU), and the other output from 4.2kHz to 66MHz in 5kHz steps. Now that is some resolution! I'll have to learn the serial I2C interface though...

Speaking of serial, I am also looking forward to interfacing a PS/2 mini-keyboard thanks to ChuckT here ( viewtopic.php?t=1601 ). Many thanks to Daryl ( http://sbc.rictor.org/ ) who "ported" his version from an Atmel ATTiny26 to an ATTiny24, which my Genius G540 programmer can burn. ATTiny24 is <$3US. It is on my "top-shelf" of priorities after my display problem is figured out.

Also, thanks to Garth, Dr. Jeffyl, BDD, & BigEd. And Andre for starting his thread which I learned alot: viewtopic.php?t=1617&postdays=0&postorder=asc&start=0

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

Not sure if that helps, but I had such problems even with CPLD, and occasionally had to do a clean build. You can do this by going in the menu to "Project" -> "Cleanup project files".

André