Component selection decisions for project Hermes
I thought I would share some of the decisions made whilst selecting the components for the design and how they impact the overall design, in terms of cost, complexity and testability.
The first big decision is the number and types of CPLD/FPGA devices for the interface logic. The original plan was to use a Xilinx XC9500XL series CPLD. Whilst they are not the most exciting of devices they have a few key benefits:
- Low cost, around the £5 to £10 unit price in small quantities.
- Available in density from 36 to 288 Macrocells.
- 5V tolerant, this reduce the amount of external logic.
- Available in solderable (for prototype) PQFP SMT packages
- Work with the free vendor design tools.
Xilinx was selected as my preferred logic vendor as I have previous experience with the devices at both a PCB implementation and at HDL level.
The majority of the design uses 3.3V logic, if the chosen CPLD can be 5V tolerant, it reduces the need for 5V to 3.3V level translation on some input only signals, like the address bus and the control bus. This is not a key feature. The number of macrocells and I/O count was surprisingly more important. The basic IDE interface required 71 I/O pins and 81 macrocells and 137 functional blocks. Factor in the extra I/O for a floppy interface and the address decode for the RAM and you have over 100 I/O pins.
An important selection criteria, for any CPLD (Xilinx, Altera or Lattice) was availability in a PQFP package as I want to avoid the BGA options. These devices tend to be limited to a 208 pin PQFP package, in up to 144 macrocells for Xilinx. Whilst the device may have 208 pins, it may only have around 100 I/O pins. The safest way to implement all the required logic is to split it across two devices as I do not want to use more than 70% of the resources (excluding pin count) of a device, to give some room for changes/routing. The IDE design is borrowed from the IDE68K project which fills a 72 macrocell CPLD. The existing CPLD design could be re-used as-is and the PCB tracked to suit?
To be decided.
Adding the SRAM memory interface and autoconfig logic (borrowed from the A608 DRAM controller which takes 22 macrocells, and 32 pins) , into another low cost CPLD seems to be a sensible split. This would be logical to add the clockport interface to.
The beauty of hardware description languages is the ability to ‘fit them’ to target devices and view their resource usage, before purchasing any components. You can also run gate level simulations but that is for another day 😉
It has been glossed over but the memory interface uses SRAM not DRAM. Component availability and simplicity of design were the key points. It is possible to procure new SRAM devices, either the Alliance, AS6C1616-55TIN, a 55ns 16 Mbit (2Mbyte) or the R1LV1616RSA-5SI#B0 could be used. They share a common 48 pin TSOP package, allowing the lowest cost part to be used. A 55ns speed grade is fine when connected to the 14 MHz (69ns) system clock of the CD32’s 68EC020 microprocessor as it takes 3 clock cycles (about 220ns) to do anything. Once the timing diagrams are finished I will publish them here.
A DRAM controller and SIMM socket would be £20-30 cheaper to implement but the lack of new SIMM sticks and the potential headache of supporting multiple , old, and potentially bad, SIMM modules, makes a common SRAM solution easier to support.
The PCB will be a 4 layer board. The cost differential was £4 per board moving from 2 layer to 4 layer but it makes the tracking so much easier as the inner two layers can be power planes with limited tracking if required. This also facilitates a controlled impedance board, important if ‘245 type buffers are used to translate 5V to 3.3V, as they have 10-20 ohm output drivers, which with appropriate series resistors, will facilitate fixing the signal integrity issues that will occur.
Once the above have been taken into account, the detailed design can begin.