Implementing PALPROM switching logic in CPLD

discuss both original and modern hardware for the bbc micro/electron
Post Reply
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Implementing PALPROM switching logic in CPLD

Post by KenLowe »

Folks,

I want to further develop my IntegraB board to allow the end user to add a number of PALPROM based ROM images to the board, and I'm looking for a bit of guidance.

The PALPROM concept has been tested on my development board, and is working well. However, the switching zones associated with the PALPROMs are hard coded into the CPLD, and I need to change this so that it would be selectable, depending upon the PALPROM type the end user wants to install. There was a bit of discussion about it in these threads:

viewtopic.php?p=300593#p300593
viewtopic.php?p=300688#p300688

The following is a more detailed functional spec to try and describe what I'm looking to implement...

I’m planning to use a 1MB RAM module that will give me 64 x 16k blocks of memory to play with. That will give me:
  • 16 x SWRAM banks (16 x 16k blocks)
  • 6 x 32k PALPROMs (12 x 16k blocks)
  • 4 x 64k PALPROMs (16 x 16k blocks)
  • 2 x 128k PALPROMs (16 x 16k blocks)
  • 1 x 32k Shadow / Private RAM (2 x 16k blocks)
  • 1 x 32k Hidden IntegraB OS (IBOS) Workspace (2 x 16k blocks)
The intention would be that each ROM bank on the beeb can be assigned to either a physical ROM socket, a SWRAM slot or PALPROM RAM slot. The RAM allocation would be as per the map below.
PALPROM1.JPG
To complicate matters further, there are up to 6 different implementations of the 32k PALPROMs, each with their own different switching zones. There are two different 64k PALPROM implementations and two different 128k PALPROM implementations. Again, I will need the end user to be able to select the correct implementation type.

To help with this, I have written some logic in the CPLD that allows me to store selection options for each of the 16 available banks. This is achieved by writing to ‘spare’ registers in the &FE3x range, and these being latched by the CPLD.
PALPROM2.JPG
The intention is then to decode the (upto) 3 bit bank type registers, and pick up the correct switching zones, which would then determine at which point a specific RAM block gets mapped in.
PALPROM3.JPG
Does this sound at all achievable using the XILINX CPLDs, or am I expecting way too much from them? I seem to run out of space quite quickly, even on the largest CPLD.

Any pointers gratefully accepted!
User avatar
hoglet
Posts: 10116
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by hoglet »

KenLowe wrote:
Thu Apr 01, 2021 6:20 pm
Does this sound at all achievable using the XILINX CPLDs, or am I expecting way too much from them? I seem to run out of space quite quickly, even on the largest CPLD.

Any pointers gratefully accepted!
There are two data points that might help:
- The device that is currently being used and it's utilization (cut/paste the table from the top of the fitter .rpt file)
- An estimate of the total number of additional registers required

Based on register utilization alone, you can make some guesses:
- If the register utilization is > 100% of the target device, then it won't fit
- If the register utilization is < 50% of the target, then it probably will fit

In between those bounds, you really have to start writing the Verilog/VHDL and see what limits you hit.

Also, is your pinout already constained?

Dave
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by KenLowe »

hoglet wrote:
Fri Apr 02, 2021 7:55 am
KenLowe wrote:
Thu Apr 01, 2021 6:20 pm
Does this sound at all achievable using the XILINX CPLDs, or am I expecting way too much from them? I seem to run out of space quite quickly, even on the largest CPLD.

Any pointers gratefully accepted!
There are two data points that might help:
- The device that is currently being used and it's utilization (cut/paste the table from the top of the fitter .rpt file)
- An estimate of the total number of additional registers required

Based on register utilization alone, you can make some guesses:
- If the register utilization is > 100% of the target device, then it won't fit
- If the register utilization is < 50% of the target, then it probably will fit

In between those bounds, you really have to start writing the Verilog/VHDL and see what limits you hit.

Also, is your pinout already constained?

Dave
Hi Dave,

I'm going to re-write the code today (assuming no side effects from my Covid jab, which I'm due to get this afternoon) to tidy it up a bit and then post it up on Github. For development purposes, I've selected the XC95288XL-10-TQ144, but I would prefer to use something smaller, if possible. I've also left the pinout totally unconstrained at this point. If memory serves me right, register utilisation was in the 80% range, but a lot of that was down to a counter I implemented, so I could switch the beeb into a special 'Recovery' mode that would allow access to normally unavailable memory, on a long press of break.

The fitter report that I attached to the following post gives an indication of the number of registers I'm using. It's not the latest code, but it lets you see where a lot of the resources are going:

viewtopic.php?p=300706#p300706

At that point I was still trying to fit everything into the XC85144XL. I then moved onto the XC85288XL, but still started running out of room as I expanded the code. I suspect my logic is not particularly well optimised!

Thanks
Ken.
wiggy
Posts: 32
Joined: Fri Feb 12, 2021 12:19 pm
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by wiggy »

Seeing that you'll need yet more registers for each of the PALPROMs (i.e. the 3 or 4 bits that were in the PALPROM's PAL) as well as the configuration ones, I think you might exceed what you can get in a CPLD.

The other issues with the CPLD architecture are that the logic is not entirely arbitrary. Just like the original PALs, you can AND a lot of signals together, but you can't OR very many. Which is great for address decoding, but tends to break down rapidly when used for general logic (generating combinatorial latches also strains this). Look at the bottom end of the fitter report for the signals that have lots of terms OR'd together and concentrate on those.
The other is that the latches (if you're using the built-in ones) appear after the logic, rather than mixed up in it. Sometimes you can re-jig your logic to work around that, but often it's not easily possible. One trick that sometimes works is to move where the registers sit in a logic path to take better advantage (e.g. here it might work out better to do more decoding before the PALPROM's registers and then latch the decoded state rather than latching the "obvious" bits and decoding afterwards). Another trick is to take signals out of a pin and route them externally into another, although that's less useful with a CPLD which can do a bit of that internally. But if you're stuck for routing to get a term from one Func Block to another, it might be a last resort.

But my gut feel here is that you ought to consider using an FPGA as better suited to this level of complexity. The downside (well, other than a complete redesign...!) is that there basically aren't any 5V FPGAs any more, so you'll have to level-shift around a 3V3 part (I like the SN74LVC8T45 / -2T45 for that). The other snag - now that you're used to the Xilinx tools - is that Xilinx aren't so keen on embedded config memory (although there are a few such as the Spartan 3AN family). That leaves a couple of options: (a) go to the competition: both Microsemi (was Actel, now bought by Microchip) and Lattice both do some nice small FPGAs with built-in config memory. Option (b) is to use a decent-sized (3V3) flash for both the FPGA's configuration, and then use the spare space as non-volatile storage for ROMs after the FPGAs booted. Your SRAM could also be 3V3 and sit on the same busses, which saves level shifting and pins.
JonHarrison
Posts: 12
Joined: Thu Mar 25, 2021 1:33 pm
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by JonHarrison »

Coming to this from a position of complete ignorance - you want to switch in 1 of 64 banks from a 1MB ? So you want to control the top 6 address bits with a CPLD? How are you planning on selecting which bank to use ?
philb
Posts: 385
Joined: Sat Aug 05, 2017 7:05 pm
Location: Cambridge, GB
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by philb »

I like the Lattice (was SiliconBlue) iCE40 family for this kind of "slightly more than a CPLD" application. They are cheap and easy to use, are quite well equipped with block RAM, and you don't have to pay for the toolchain. Also the tools run on Linux which is a bonus for me.

Downsides: the onboard config memory is OTP, so in practice I virtually never use it. And although they have several densities and many package options, in practice the matrix is quite sparsely populated and any given package tends only to support one density (and vice versa). This is a bit irritating if you're trying to design the PCB before the logic is fully developed, because you end up having to guess at what device your design will ultimately fit into. Also quite a lot of their focus is on very small-geometry packages (WLCSP or micro-BGA) which are a bit painful from a layout and assembly perspective.
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by KenLowe »

JonHarrison wrote:
Sat Apr 03, 2021 9:29 am
Coming to this from a position of complete ignorance - you want to switch in 1 of 64 banks from a 1MB ? So you want to control the top 6 address bits with a CPLD? How are you planning on selecting which bank to use ?
That's correct. The CPLD will control the upper address bits of the RAM.

Within the CPLD design there two different methods of switching in the 16k blocks of RAM:
  • Firstly, for each of the 16 available ROM slots, there is a soft switch that allows the user to select either ROM socket, SWRAM, or emulated PALPROM module. This switching is currently done by writing data to locations in the &FE3x range, but it will eventually be done with a * command from the IntegraB support ROM (IBOS ROM).
  • Secondly, if you've selected one of the emulated PALPROMs, there is special switching code in the CPLD that will switch in the appropriate 16k blocks of RAM, and this is where the majority of the 64 banks of RAM are assigned. The switching code in the CPLD is based on reverse engineering of the various different PALPROM devices (eg SpellMaster, or ConQuest) that are available. The different PALPROMs devices use a variety of different switching logic schemes to map in and out the appropriate 16k blocks of memory. The PALPROMs also vary in the size of ROMs they interface with (32k, 64k & 128k). I want to try and cater for these different PALPROM types in the CPLD. This is where the CPLD logic starts getting a bit complicated and is why I'm running short of space.
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by KenLowe »

wiggy wrote:
Fri Apr 02, 2021 10:19 pm
Seeing that you'll need yet more registers for each of the PALPROMs (i.e. the 3 or 4 bits that were in the PALPROM's PAL) as well as the configuration ones, I think you might exceed what you can get in a CPLD.

The other issues with the CPLD architecture are that the logic is not entirely arbitrary. Just like the original PALs, you can AND a lot of signals together, but you can't OR very many. Which is great for address decoding, but tends to break down rapidly when used for general logic (generating combinatorial latches also strains this). Look at the bottom end of the fitter report for the signals that have lots of terms OR'd together and concentrate on those.
The other is that the latches (if you're using the built-in ones) appear after the logic, rather than mixed up in it. Sometimes you can re-jig your logic to work around that, but often it's not easily possible. One trick that sometimes works is to move where the registers sit in a logic path to take better advantage (e.g. here it might work out better to do more decoding before the PALPROM's registers and then latch the decoded state rather than latching the "obvious" bits and decoding afterwards). Another trick is to take signals out of a pin and route them externally into another, although that's less useful with a CPLD which can do a bit of that internally. But if you're stuck for routing to get a term from one Func Block to another, it might be a last resort.

But my gut feel here is that you ought to consider using an FPGA as better suited to this level of complexity. The downside (well, other than a complete redesign...!) is that there basically aren't any 5V FPGAs any more, so you'll have to level-shift around a 3V3 part (I like the SN74LVC8T45 / -2T45 for that). The other snag - now that you're used to the Xilinx tools - is that Xilinx aren't so keen on embedded config memory (although there are a few such as the Spartan 3AN family). That leaves a couple of options: (a) go to the competition: both Microsemi (was Actel, now bought by Microchip) and Lattice both do some nice small FPGAs with built-in config memory. Option (b) is to use a decent-sized (3V3) flash for both the FPGA's configuration, and then use the spare space as non-volatile storage for ROMs after the FPGAs booted. Your SRAM could also be 3V3 and sit on the same busses, which saves level shifting and pins.
I think you're right about the CPLD architecture causing me issues here, as I will have quite a lot of logical ORs that need to be implemented. I've also just had a discussion with some of the guys on the ABUG Zoom call, and the general view was that I needed to select a bigger device. I'm going to start looking at some of the FPGA solutions, and see if I can find something that will work for me. The level shifting isn't a big issue for me. The bigger issue will be learning how to work with FPGAs. I've only just become comfortable with CPLDs!
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by KenLowe »

philb wrote:
Sat Apr 03, 2021 9:55 am
I like the Lattice (was SiliconBlue) iCE40 family for this kind of "slightly more than a CPLD" application. They are cheap and easy to use, are quite well equipped with block RAM, and you don't have to pay for the toolchain. Also the tools run on Linux which is a bonus for me.

Downsides: the onboard config memory is OTP, so in practice I virtually never use it. And although they have several densities and many package options, in practice the matrix is quite sparsely populated and any given package tends only to support one density (and vice versa). This is a bit irritating if you're trying to design the PCB before the logic is fully developed, because you end up having to guess at what device your design will ultimately fit into. Also quite a lot of their focus is on very small-geometry packages (WLCSP or micro-BGA) which are a bit painful from a layout and assembly perspective.
I'll have a look at that, thanks. Although BGA will be a non starter for me!
JonHarrison
Posts: 12
Joined: Thu Mar 25, 2021 1:33 pm
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by JonHarrison »

Firstly, for each of the 16 available ROM slots, there is a soft switch that allows the user to select either ROM socket, SWRAM, or emulated PALPROM module. This switching is currently done by writing data to locations in the &FE3x range, but it will eventually be done with a * command from the IntegraB support ROM (IBOS ROM).
Secondly, if you've selected one of the emulated PALPROMs, there is special switching code in the CPLD that will switch in the appropriate 16k blocks of RAM, and this is where the majority of the 64 banks of RAM are assigned. The switching code in the CPLD is based on reverse engineering of the various different PALPROM devices (eg SpellMaster, or ConQuest) that are available. The different PALPROMs devices use a variety of different switching logic schemes to map in and out the appropriate 16k blocks of memory. The PALPROMs also vary in the size of ROMs they interface with (32k, 64k & 128k). I want to try and cater for these different PALPROM types in the CPLD. This is where the CPLD logic starts getting a bit complicated and is why I'm running short of space.
So the first is a compare on the address lines to match the &FE3x address range together with the write line and then latch the data lines into your upper address space and the second is indexing into a 6-bit lookup table ?
philb
Posts: 385
Joined: Sat Aug 05, 2017 7:05 pm
Location: Cambridge, GB
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by philb »

KenLowe wrote:
Sat Apr 03, 2021 11:04 am
I'll have a look at that, thanks. Although BGA will be a non starter for me!
Yeah, the worst thing about their BGAs is that they have 0.4mm ball pitch which pretty much means you need to use microvias. But they do offer some parts in more conventional packages too. I use the iCE40HX1K in the 100-pin VQFP quite a lot. If you only need a small device, which you probably do if a CPLD is "nearly" enough, they also have the iCE40LP384 in a 32-pin QFN which is not too bad to lay out.
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by KenLowe »

JonHarrison wrote:
Sat Apr 03, 2021 12:16 pm
Firstly, for each of the 16 available ROM slots, there is a soft switch that allows the user to select either ROM socket, SWRAM, or emulated PALPROM module. This switching is currently done by writing data to locations in the &FE3x range, but it will eventually be done with a * command from the IntegraB support ROM (IBOS ROM).
Secondly, if you've selected one of the emulated PALPROMs, there is special switching code in the CPLD that will switch in the appropriate 16k blocks of RAM, and this is where the majority of the 64 banks of RAM are assigned. The switching code in the CPLD is based on reverse engineering of the various different PALPROM devices (eg SpellMaster, or ConQuest) that are available. The different PALPROMs devices use a variety of different switching logic schemes to map in and out the appropriate 16k blocks of memory. The PALPROMs also vary in the size of ROMs they interface with (32k, 64k & 128k). I want to try and cater for these different PALPROM types in the CPLD. This is where the CPLD logic starts getting a bit complicated and is why I'm running short of space.
So the first is a compare on the address lines to match the &FE3x address range together with the write line and then latch the data lines into your upper address space and the second is indexing into a 6-bit lookup table ?
Almost. The first part is correct, but the second bit is more complex...

All 16 ROM banks will have a dedicated 3 bit wide register that defines what is mapped into that ROM bank, with the 3 bit register allowing a total of 8 possible combinations (either an external ROM, or a standard SWRAM bank or one of a number of different PALPROM types). For example, ROM bank 10 can be mapped to one of the following, which would be selected based on the value in the 3 bit wide register:
  1. External ROM socket
  2. Standard 16k SWRAM (16k Block 10)
  3. 32k PALPROM switch type 1 (Extended 16k Blocks 22 & 34)
  4. 32k PALPROM switch type 2 (Extended 16k Blocks 22 & 34)
  5. 32k PALPROM switch type 3 (Extended 16k Blocks 22 & 34)
  6. 32k PALPROM switch type 4 (Extended 16k Blocks 22 & 34)
  7. 32k PALPROM switch type 5 (Extended 16k Blocks 22 & 34)
  8. 32k PALPROM switch type 6 (Extended 16k Blocks 22 & 34)
If having selected one of the PALPROM types, the CPLD logic will then need to monitor the address bus, and switch in and out the extended RAM blocks based on the address bus matching a predefined value (referred to as the 'switching address'). Each PALPROM type uses a range of different switching address bus values to switch in and out the extended RAM.

The above example is for ROM bank 10 only.

The other 15 ROM banks will have their own independent selection options based on their 3 bit wide register, in accordance with the tables I posted previously. So for example, ROM bank 8 can be mapped to one of the following, which would be selected based on the value in the 3 bit wide register:
  1. External ROM socket
  2. Standard 16k SWRAM (16k Block 8 )
  3. 128k PALPROM switch type 1 (Extended 16k Blocks 20, 32, 44, 50, 52, 54, 56 & 58)
  4. 128k PALPROM switch type 2 (Extended 16k Blocks 20, 32, 44, 50, 52, 54, 56 & 58)
Hope that makes some sense!
JonHarrison
Posts: 12
Joined: Thu Mar 25, 2021 1:33 pm
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by JonHarrison »

Yes that makes sense and I can understand how the CPLD could quickly run out of cells. So, could you implement the lookup table in an external PROM so that your CPLD just provides the decode for the PROM address lines and the PROM data lines drive your pcb address bus ? Or use a larger FPGA or an FPGA with internal flash for the lookup table.
Ramtop
Posts: 279
Joined: Tue Oct 23, 2018 1:40 pm
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by Ramtop »

A low end FPGA is probably the way to go if the design goes beyond the capacity of a 9572. Even with the cost of level shifters it's probably cheaper than a 95144, albeit a bit harder to route.
Gary
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by KenLowe »

JonHarrison wrote:
Wed Apr 07, 2021 9:26 am
Yes that makes sense and I can understand how the CPLD could quickly run out of cells. So, could you implement the lookup table in an external PROM so that your CPLD just provides the decode for the PROM address lines and the PROM data lines drive your pcb address bus ?
I could possibly use a ROM as a look up table and use the data output bits of the ROM to drive the upper address bits in the RAM. I'd likely need quite a large ROM to ensure the address bus is wide enough to cater for all the combinations of ROM banks (4 bit), PALPROM types (3 bit), and PALPROM extended bank switching (need to think about the best way to do this), Shadow / Private RAM(1 bit), IBOS workspace (1bit).
JonHarrison wrote:
Wed Apr 07, 2021 9:26 am
Or use a larger FPGA or an FPGA with internal flash for the lookup table.
Ramtop wrote:
Wed Apr 07, 2021 12:58 pm
A low end FPGA is probably the way to go if the design goes beyond the capacity of a 9572. Even with the cost of level shifters it's probably cheaper than a 95144, albeit a bit harder to route.
I've been trying to fit everything into a XC95144XL, and even moved to the larger XC95288, but keep running out of space - even on a fully unconstrained layout, so I've been thinking about moving over to the Spartan XC6SLX9-2TQG144C FPGA. That'll be a new experience for me!
User avatar
hoglet
Posts: 10116
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by hoglet »

KenLowe wrote:
Wed Apr 07, 2021 2:24 pm
I've been trying to fit everything into a XC95144XL, and even moved to the larger XC95288, but keep running out of space - even on a fully unconstrained layout, so I've been thinking about moving over to the Spartan XC6SLX9-2TQG144C FPGA. That'll be a new experience for me!
I'm currently running an FPGA based system that includes: BBC Master, 65C02 Second Processor, VideoNuLA, Music 5000, 6502-ICE Debugger.

This all fits in an XC6SLX9 (with an external SRAM for the BBC RAM/ROM).

So you should be OK on space with that!
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by KenLowe »

hoglet wrote:
Wed Apr 07, 2021 2:39 pm
I'm currently running an FPGA based system that includes: BBC Master, 65C02 Second Processor, VideoNuLA, Music 5000, 6502-ICE Debugger.

This all fits in an XC6SLX9 (with an external SRAM for the BBC RAM/ROM).
Do you have any recommendations on a development board? I was thinking about something like this:

https://www.ebay.co.uk/itm/Mojo-V3-FPGA ... 4723693241

Does that look reasonable?
hoglet wrote:
Wed Apr 07, 2021 2:39 pm
So you should be OK on space with that!
Have you not seen how badly and inefficiently I write my logic??? :lol: :lol: :lol:
Last edited by KenLowe on Wed Apr 07, 2021 3:01 pm, edited 1 time in total.
philb
Posts: 385
Joined: Sat Aug 05, 2017 7:05 pm
Location: Cambridge, GB
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by philb »

CPLD to XC6SLX9 is certainly quite a jump! Is XC6SLX4-2TQG144C not enough for what you need? Not that there's any harm in using the larger part of course, it just sounds like it'll end up only about 10% utilised.
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by KenLowe »

philb wrote:
Wed Apr 07, 2021 3:01 pm
CPLD to XC6SLX9 is certainly quite a jump! Is XC6SLX4-2TQG144C not enough for what you need? Not that there's any harm in using the larger part of course, it just sounds like it'll end up only about 10% utilised.
The reason I selected that part is because it's one of the parts that JLCPCB have in stock for assembly. The smallest they seem to do is the SLX9:

https://jlcpcb.com/parts/componentSearc ... Txt=xc6slx

I could select a smaller part, and do the soldering myself, but I'd rather have it done by someone else, and the cost isn't horrendous!
philb
Posts: 385
Joined: Sat Aug 05, 2017 7:05 pm
Location: Cambridge, GB
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by philb »

Aha, right, got it. Fair enough! I also prefer to have others do the soldering given the choice.
User avatar
hoglet
Posts: 10116
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by hoglet »

KenLowe wrote:
Wed Apr 07, 2021 2:53 pm
Do you have any recommendations on a development board? I was thinking about something like this:

https://www.ebay.co.uk/itm/Mojo-V3-FPGA ... 4723693241

Does that look reasonable?
The Mojo-V3 is a reasonable choice if you want a minimal dev board. It's open source and there are several suppliers.

I have used the very similar EEPIZZA board for several of my projects, but it's been hard to get recently.
https://www.ebay.co.uk/itm/XC6SLX9-Core ... 4663155388

(I use this in the 6502-ICE and also the Beeb 1MHz Bus FPGA projects)

It also depends whether you want to do other things with it, beside the PALPROM.

Dave
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by KenLowe »

hoglet wrote:
Wed Apr 07, 2021 3:46 pm
The Mojo-V3 is a reasonable choice if you want a minimal dev board. It's open source and there are several suppliers.

I have used the very similar EEPIZZA board for several of my projects, but it's been hard to get recently.
https://www.ebay.co.uk/itm/XC6SLX9-Core ... 4663155388

(I use this in the 6502-ICE and also the Beeb 1MHz Bus FPGA projects)

It also depends whether you want to do other things with it, beside the PALPROM.

Dave
Duh! ok, I received one of those boards just the the other week. I didn't realise it had the XC6SLX9 on it!!! It's been sat right in front of me all this time #-o

Edit: Talk about co-incidences. Just received this in the email this afternoon :roll: :
email
email
User avatar
hoglet
Posts: 10116
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by hoglet »

KenLowe wrote:
Wed Apr 07, 2021 4:14 pm
Edit: Talk about co-incidences. Just received this in the email this afternoon :roll: :
Here's some feedback you could give him....

If he could indicate on ebay this item was in stock, he would likely sell quite a few more!
JonHarrison
Posts: 12
Joined: Thu Mar 25, 2021 1:33 pm
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by JonHarrison »

I could possibly use a ROM as a look up table and use the data output bits of the ROM to drive the upper address bits in the RAM. I'd likely need quite a large ROM to ensure the address bus is wide enough to cater for all the combinations of ROM banks (4 bit), PALPROM types (3 bit), and PALPROM extended bank switching (need to think about the best way to do this), Shadow / Private RAM(1 bit), IBOS workspace (1bit).
How about using a serial PROM and serialise / deseralise into a parallel register inside the CPLD ?
wiggy
Posts: 32
Joined: Fri Feb 12, 2021 12:19 pm
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by wiggy »

JonHarrison wrote:
Thu Apr 08, 2021 12:26 pm
How about using a serial PROM and serialise / deseralise into a parallel register inside the CPLD ?
By the time you've got that shift register, another for the outbound address, plus a state machine to run them... well, we started out register-starved anyway. The other issue is you'll need to be able to update the address fast enough to be able to switch sideways ROM in time for the CPU to jump to it... you'll either need to generate a 10's of MHz clock for the PROM or to stall the 6502's fetch somehow.

I'd toyed briefly with suggesting a ROM solution, but as soon as you factor in the both the type configuration bits and each PALPROM's selection bits (adding up to potentially 6 or 7 bits per ROM slot) the ROM ceases to be a practical solution. The logic version is simpler than the full-up lookup version.

What might work well, though is to have a tiny lookup ROM (128x4 or so) for each ROM slot - turning the configuration & selection into some high-order address bits - then multiplex those by the ROMSEL output. Now you can't do that physically (well, not sensibly!), but it would drop into the FPGA just fine. You might alternatively be able to use a single common lookup ROM, use ROMSEL to multiplex the appropriate type/selection register into it, and then add the output to (say) a ROMSEL-selected base-address register. That should optimise nicely in an FPGA.
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by KenLowe »

wiggy wrote:
Thu Apr 08, 2021 1:53 pm
JonHarrison wrote:
Thu Apr 08, 2021 12:26 pm
How about using a serial PROM and serialise / deseralise into a parallel register inside the CPLD ?
By the time you've got that shift register, another for the outbound address, plus a state machine to run them... well, we started out register-starved anyway. The other issue is you'll need to be able to update the address fast enough to be able to switch sideways ROM in time for the CPU to jump to it... you'll either need to generate a 10's of MHz clock for the PROM or to stall the 6502's fetch somehow.

I'd toyed briefly with suggesting a ROM solution, but as soon as you factor in the both the type configuration bits and each PALPROM's selection bits (adding up to potentially 6 or 7 bits per ROM slot) the ROM ceases to be a practical solution. The logic version is simpler than the full-up lookup version.
That's pretty much where I landed on the lookup table option.
wiggy wrote:
Thu Apr 08, 2021 1:53 pm
What might work well, though is to have a tiny lookup ROM (128x4 or so) for each ROM slot - turning the configuration & selection into some high-order address bits - then multiplex those by the ROMSEL output. Now you can't do that physically (well, not sensibly!), but it would drop into the FPGA just fine. You might alternatively be able to use a single common lookup ROM, use ROMSEL to multiplex the appropriate type/selection register into it, and then add the output to (say) a ROMSEL-selected base-address register. That should optimise nicely in an FPGA.
My head is starting to hurt! I started re-writing the logic yesterday, and I'm hoping to be able to break it down into a number of defined modules, which will hopefully do something similar to ROM lookup. ROMSEL will definitely form part of that!
wiggy
Posts: 32
Joined: Fri Feb 12, 2021 12:19 pm
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by wiggy »

KenLowe wrote:
Thu Apr 08, 2021 2:27 pm
My head is starting to hurt!
Sorry - I was afraid that would happen.

With apologies for the poor drawings (I knew I should have used !Draw not MS Word, which today apparently has got its grid on the skew??...) here are a couple of sketches of what I had in mind.

"Option 1" has one lookup/logic block per ROM-slot:
Option 1
Option 1
"Option 2" has the shared lookup/logic. Although Option 2 looks more complicated it probably uses up less logic resources.
Option 2
Option 2
But you're quite right that the way to approach this (like most problems) is to break it up into blocks.
User avatar
KenLowe
Posts: 1757
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Implementing PALPROM switching logic in CPLD

Post by KenLowe »

I've selected the XC6SLX9 FPGA in ICE, and I'm slowly progressing with the logic development. So far so good. No space issues to report, but still got quite a lot of coding to do. Given what's been said already, I'm not expecting to run into any issues here!

In parallel, I've been looking at the hardware side of this and (rather predictably) I'm struggling to know where to start! I've got the EEPIZZA development board which I'm hoping will be fine for testing, but my ultimate aim will be to have the XC6SLX9 soldered direct onto my board, and I'm trying to work out what supporting hardware I need (eg serial EEPROM) and how to configure this in the ICE development system. I want to keep it as simple as possible, and have been looking for some guides / worked examples, but struggling to find anything suitable.

Does anyone have links to any simple guides that I could follow?

Thanks
Post Reply

Return to “8-bit acorn hardware”