I don't understand this:

What's to understand? I'm not going to build a PCB at this stage, so the packaging of the level shifters is enough to influence the choices. What's more, the level shifters will exceed the cost of the FPGA, at least if you intend to use more than 20% of the I/O's, so that's a factor too. What's more, they have a real impact on external timing.



In theory, it should work just fine, as most 5V0 logic recognizes as "high" inputs down to 2.65 volts or so and the SP-3's then simply want resistors to limit the input current. It's only a problem for bidirectional signals, like the external data bus. Ultimately, the justification for using an FPGA in the first place is to keep the "external" stuff internal to the FPGA, If you have to use external hardware in addition to an FPGA, it's hard to justify the cost. It would probably be easier and thriftier to use a CPLD external to one of the SiLabls parts.


My interest, in this case, is in the ability to test the resulting circuit in a real-world situation, which means, basically, setting it up in place of a "standard" 805x.

I'd simply build a little adapter that takes the signals from my FPGA board and moves them, either with a "hard" adapter, i.e. a fixed adapter using no cables, or with an adapter cable, to the DIP-40 (PLCC-44 would be a mite more difficult) site on a functional board, and then see what happens. That's why I'm fooling with the SP2 part.

This is essentially just a mental masturbation exercise, but it needs a physical test. SP2's are not generously equipped with RAM, so you can't put the code space inside, beyond, say, the basic 4KB that the original 8051 had. The XC2S300E, IIRC had 8 KB of block ram, but since I'd need a code space of 4KB configured as a 48-bit-wide block, and a 256x17 {?} ROM block to decode the opcodes, and 256x8 of RAM, plus ... well, you get the idea ... Keep in mind that I'm after a version that executes all instructions except, perhaps, mul and div in one clock. The clock doesn't have to be >100 MHz, but I'm after an aggregate rate closer to 100 MIPS than 50.

The performance of these devices is something that's been called into question from time to time, owing mainly to the confusion created by the marketing literature. The claim has been that SP2's, for example, can count at rates exceeding 200 MHz. I've observed that they can divide by two at that rate, but, according to their timing analyzer, a 16-bit counter won't run at much over 80 MHz unless you give it special care. I suppose ripple counters can go faster, but you can't do much other than divide with them ... you certainly wouldn't want to decode one.

Those big muxes that would be required to form the data paths from mapped space, including code, idata, xdata, and SFR's, to the ALU, and from the ALU to device pins, I/O, and back to mapped space, can be implemented as tristates in SP2. That's easier. As one migrates to the current technology, however, it's necessary to know what one can do with those features that were not so important in the SP2 technology unless you were processing digitized signals. The lack of those tri-state features means that understanding what fast multiplexing options are available is vitally important. I seriously doubt that the software will use its imagination to utilize the fast-carry logic in a logic cell when all you've done is to instantiate a mux.

I'm looking for some way to find out what one can do with a logic cell aside from the obvious. They describe ways of using a single LUT as a 5-input function generator. They describe ways of doing other things, too, but most of the time they simply telly you that there's a way, but don't tell you how to use it or how to make it happen.

If you don't know you can do a specific thing with their hardware, you won't attempt it, will you? Moreover, without endless hours of poring over their reports, you really won't know how it did this or that.

RE