There was a thread asking for smaller ones, now I am asking for bigger ones that can fit a MMU in. The target processor is 68010/68331. (I know 68331 can run at 3.3V coupled to XC6SLX9 but it also runs at 5V and 68010 flat out requires 5V)
Or how do I implement proper level shifting? I know it uses rows of 74LVC8T245 but how to control the DIR bad OE lines?
I have a similar requirement... I would effectively want to build a Fluke 9010A Z80, 6809,... Pod in modern technology.
So lots of I/o at 5V TTL which I need to be in, out or Z
It's a bit overwelming how much buffer logic is required and your buses are even wider
I have a similar requirement... I would effectively want to build a Fluke 9010A Z80, 6809,... Pod in modern technology.
So lots of I/o at 5V TTL which I need to be in, out or Z
It's a bit overwelming how much buffer logic is required and your buses are even wider
So far the best chance I have is use the older Xilinx Spartan-II series, which has 5V-tolerant I/O, as a bus matrix and and level shifter. This does allow me to run the rest of the system on 3.3V though, permitting the use of cheap 16-bit 3.3V SRAM and NOR Flash chips. Now the question is how to bootstrap it.
For your pod since this Xilinx FPGA is reasonably big, the actual core to be emulated can be a full featured, clock accurate soft core in the FPGA, while debug access can be made by adding hardware into that soft core.
I think I am going to work on the basis of current production hardware only otherwise I head towards premature obsolescence. So... 3v3 FPGA for me.
It is daunting and hence I am still on, or slightly before, the drawing board.
The Fluke Pods are simple in the sense that they utilise the target processor but indeed... a softcore implementation works in my case... however there are many twists... eg. DRAM refresh
Will be a fun project once I'm brave enough to get started.
It's a bit overwhelming how much buffer logic is required
yup, 8 chips for interfacing a 32bit data bus and 24bit address space CPU, and it's just for the voltage level shifting stuff
or! a large (>60pins?) 5V-tolerant CPLD, programmed as a buffer and used only for the purpose of translating the voltage to the FPGA.
or! a large (>60pins?) 5V-tolerant CPLD, programmed as a buffer and used only for the purpose of translating the voltage to the FPGA.
Actually that might be a pretty sensible solution, and make PCB layout easier as you have a lot of control of the pinout.
Could you do some of the logic in the CPLD to reduce the number of lines to the FPGA?
It's a bit overwhelming how much buffer logic is required
yup, 8 chips for interfacing a 32bit data bus and 24bit address space CPU, and it's just for the voltage level shifting stuff
or! a large (>60pins?) 5V-tolerant CPLD, programmed as a buffer and used only for the purpose of translating the voltage to the FPGA.
That seem like a job for Intel EPM240 MAX II CPLD. Still supported as the lowest end Intel offer and cheap.
Could you do some of the logic in the CPLD to reduce the number of lines to the FPGA?
Sure, Modern CPLD like that MAX II EPM240 is almost just mini-FPGA with internal configuration storage.
If you can find old stock somewhere, IIRC Lattice's iCE65 was 5V-tolerant.
or! a large (>60pins?) 5V-tolerant CPLD, programmed as a buffer and used only for the purpose of translating the voltage to the FPGA.
Actually that might be a pretty sensible solution, and make PCB layout easier as you have a lot of control of the pinout.
Could you do some of the logic in the CPLD to reduce the number of lines to the FPGA?
Exactly the sort of thinking I have been mulling over (procrastinating)... my problem is actually doubled since how the Fluke actually works is to drive the buses weakly and then sample them (74SC374s) as a way of detecting if they are inadvertently being pulled high or low due to a problem chip, this sampling is very valuable for old arcade board repair since this is a common failure mode... but it does double the number of lines that need to be 5V tolerant.
or! a large (>60pins?) 5V-tolerant CPLD, programmed as a buffer and used only for the purpose of translating the voltage to the FPGA.
Actually that might be a pretty sensible solution, and make PCB layout easier as you have a lot of control of the pinout.
Could you do some of the logic in the CPLD to reduce the number of lines to the FPGA?
Exactly the sort of thinking I have been mulling over (procrastinating)... my problem is actually doubled since how the Fluke actually works is to drive the buses weakly and then sample them (74SC374s) as a way of detecting if they are inadvertently being pulled high or low due to a problem chip, this sampling is very valuable for old arcade board repair since this is a common failure mode... but it does double the number of lines that need to be 5V tolerant.
Depending on CPLD, it might have a weak output mode cutting the pin count in half again.
If you can find old stock somewhere, IIRC Lattice's iCE65 was 5V-tolerant.
Altera Flex10K was 5V-tolerant, too, as well as QuickLogic. I don't know about QL, but the Flex10K seems still in use in avionics, therefore I can guaranty at least one of my customer must still have a copy of QuartusII v5 which support this old FPGA
If you can find old stock somewhere, IIRC Lattice's iCE65 was 5V-tolerant.
Altera Flex10K was 5V-tolerant, too, as well as QuickLogic. I don't know about QL, but the Flex10K seems still in use in avionics, therefore I can guaranty at least one of my customer must still have a copy of QuartusII v5 which support this old FPGA
I am settling on MAX II and Spartan II. Spartan II is old and unsupported but still pretty abundent here in China online. MAX II is supported.
If you can find old stock somewhere, IIRC Lattice's iCE65 was 5V-tolerant.
Altera Flex10K was 5V-tolerant, too, as well as QuickLogic. I don't know about QL, but the Flex10K seems still in use in avionics, therefore I can guaranty at least one of my customer must still have a copy of QuartusII v5 which support this old FPGA
I wonder if it is possible to copy support files from an older version of Quartus to a newer one and have it still work, maybe after a minor hack satisfying the version check? If so they might be able to carry Flex10K to Quartus Prime.
I wonder if it is possible to copy support files from an older version of Quartus to a newer one
Judging from what I can list (unfortunately can't download) from their server: probably it doesn't work. I see a list of virtual machines with text files telling what the archive contains and for which project it is. It seems guys on the space defense area are still using the old Flex10K for - I don't know what - related to their radars engine.
It means the IT-guys must have already considered this problem and found that saving QuartusII v5 in a virtual machine is more practical than trying to integrate an unsupported device in a modern development system
Spartan II are very nice, they need 2 VCCs 2.5 and 3.3V only (the IOs could go to 1.8 or maybe lower). But beaware that the clock inputs are not general purpose pins like in the Spartan 3 !, you can use them as inputs but not as outputs.
Spartan II E are not 5 V tolerant. The MAX II is also not 5 V tolerant.
You need an old version of the software for Spartan II also, the more recent versions of ISE don't support it.
That is something I find annoying about FPGA software, it would really be nice if they would retain support for older devices.
Or how do I implement proper level shifting? I know it uses rows of 74LVC8T245 but how to control the DIR bad OE lines?
Control them from the A side.
They also have sn74LVC16T245 with 16 channels in small packages, They have 20-channel shifters too, but I'm not sure they have it in LVC variety.
If you want to control direction of individual pins, you can use sn74LVC1T245 which is a single-channel chip. As far as I know there's no big shifter chips which would have individual controls for each channel. They all are designed for buses.
Or how do I implement proper level shifting? I know it uses rows of 74LVC8T245 but how to control the DIR bad OE lines?
Control them from the A side.
They also have sn74LVC16T245 with 16 channels in small packages, They have 20-channel shifters too, but I'm not sure they have it in LVC variety.
If you want to control direction of individual pins, you can use sn74LVC1T245 which is a single-channel chip. As far as I know there's no big shifter chips which would have individual controls for each channel. They all are designed for buses.
Assuming that the 68010 is on the A side, and I has a EPM7032 there as a small 5V-only CPLD for glue logic, I know that address and control lines only go from A side to B side but how do I determine when to disable OE? As of the data bus what signal should be used to control direction? Can I just parallel the OE of the two sets of the bus or do I need separate OE's?
PSoC
Too small, and have no use for the hard core and the bulk of the chip.
I believe atmel/microchip still make and sell 5v cpld and fpga(atf15/at40k)
Assuming that the 68010 is on the A side, and I has a EPM7032 there as a small 5V-only CPLD for glue logic, I know that address and control lines only go from A side to B side but how do I determine when to disable OE? As of the data bus what signal should be used to control direction? Can I just parallel the OE of the two sets of the bus or do I need separate OE's?
There's only one OE, and one DIR. They both are controlled from the A side. In sn74LVC16T245 there are two 8-channel circuits, both with their own OE and DIR. All these are controlled from the same side (which is side A on the pinouts). So, of course, you can parallel them.
Assuming that the 68010 is on the A side, and I has a EPM7032 there as a small 5V-only CPLD for glue logic, I know that address and control lines only go from A side to B side but how do I determine when to disable OE? As of the data bus what signal should be used to control direction? Can I just parallel the OE of the two sets of the bus or do I need separate OE's?
There's only one OE, and one DIR. They both are controlled from the A side. In sn74LVC16T245 there are two 8-channel circuits, both with their own OE and DIR. All these are controlled from the same side (which is side A on the pinouts). So, of course, you can parallel them.
So rounding up, I need three 74LVC16T245 and one 74LVC1T45:
* one 16T245 for the data bus,
* one and half 16T245 for the address bus,
* the remaining half for the control bus except BG,
* and the 1T45 are specifically for the BG line.
The DIR of the address/control buses would be tied to a fixed level since the signal travel only one way, and the DIR of the data bus derives from the R/W signal from the CPU. The OE of all three bus shifter chip are paralleled together and derived from the BG signal. The 1T45 has fixed direction and is always enabled.
CPU inputs are fed directly with 3.3V CMOS outputs counting on the fact that 3.3V CMOS output levels can be correctly understood by 5V TTL inputs.
Now the 68010 can sit in its own 5V island, and the rest of the system can be implemented using standard 3.3V LVCMOS components like IS62WV51216BLL-55TLI 16-bit 1MB SRAM, M29W160EB-75 16-bit 2MB NOR Flash and XC6SLX9-2PQG144A FPGA.
You need an old version of the software for Spartan II
just checked my customer's sw-list: ISE v10.1 is what they are using for Spartan2 and Spartan2E
You need an old version of the software for Spartan II
just checked my customer's sw-list: ISE v10.1 is what they are using for Spartan2 and Spartan2E
If I recalled it right, the latest ISE thatsupports Spartan II is in the version 11.x series.
I think I found a way out of this on 68010: that chip, while requires 5V operation, is capped at 2.4V VOH. So maybe just put a 510 ohm series resistor in there to soften the glitches if there is any and just wire that directly into the 3.3V system as-is.