POC VERSION TWO

[GARTHWILSON]

BillO wrote:

to have one board at 16mHz, one at 14mHz, one at 10mHz one at 4mHz and one at about 2 mHz.

Er... make that "MHz" (megaHertz), not "mHz" (milliHertz). 1MHz is 1,000,000,000 mHz.

[BillO]

Quote:

Er... make that "MHz" (megaHertz), not "mHz" (milliHertz). 1MHz is 1,000,000,000 mHz.

Right you are! I'll take a billion times improvement any day, even if it's only a North American billion.

[BigDumbDinosaur]

BillO wrote:

BigDumbDinosaur wrote:

It's an obsolete part, according to ST Microelectronics, and also is not adaptable to POC V2, due to differing package sizes.

It's too bad it won't fit.

As to the obsolete thing, I usually don't let that bother me as long as they are still available from somewhere. I never plan to commercialize this. I usually just buy enough for any foreseeable needs of my own. I got 10 of these for about a $1 a piece. For my current project I expect to have one board at 16mHz, one at 14mHz, one at 10mHz one at 4mHz and one at about 2 mHz. This way I can have a common platform that will run interfaces of all speeds. The slower 3 will work with some 70nS EPROM chips I have so I'll still have 8 of the faster ones for future use.

The 55ns EPROMs I have are AMD 27C256-55 parts that are readily available through distribution. I get them from JAMECO.

[BigDumbDinosaur]

GaBuZoMeu wrote:

BigDumbDinosaur wrote:

I have been cogitating about an apparent hardware/logic flaw present in both of my POC V2 designs, one that may be contributing to instability.

Can you elaborate what kind of mis- or unexpected behavior causes you to think about some design error?
Is this behavior repeatable? Can you influence it (e.g. clock speed, voltage, ...) ?

The machine crashes now and then, with no apparent pattern to it. As it is powered from a regulated 5 volt source, I do not believe that is the cause. Slowing down Ø2 doesn't seem to matter.

[BillO]

BigDumbDinosaur wrote:

[... no apparent pattern ...

Sorry BDD, but this is the (in my experience) worst possible scenario. However, we are dealing with digital so the only truly randomly intermittent issues would be caused by marginal timing tolerances, out of spec components, physical issues like cold solder joints or cracked traces/vias, or simply (no, not really simple) not taking all possible execution scenarios into account (this last one may - seem - intermittent, but in actuality is not).

The two hardest of those to diagnose are - marginal timing tolerances and not taking all possible execution scenarios into account. My recent problems with my project were related to marginal timing issues that were not speed dependent. You helped out with that. This may be something you want to look at, but I don't believe it is your problem.

Further, dealing with all possible execution scenarios is also very tough to get a handle on. I remember using a HP 1661A logic analyzer (which I still have) for such things. First you have to figure out how to attach all the probes (no easy task on most modern boards), then you have to be able to define the trigger criterion so that you can record the event you want to analyze. Sometimes (most times) it is easier and more expedient to write down all possible execution scenarios, then hand analyze how your system will deal with each one, after which you can use a logic analyzer to look at the suspect scenarios.

Step by step...

[BigEd]

Other than slowing down the clock, the other relatively easy variable to explore is voltage. If the machine's crash rate is unchanged at slightly high and slightly low VDD, it's more likely to be a digital problem, otherwise more likely to be a timing problem.

[GaBuZoMeu]

BigDumbDinosaur wrote:

The machine crashes now and then, with no apparent pattern to it. As it is powered from a regulated 5 volt source, I do not believe that is the cause. Slowing down Ø2 doesn't seem to matter.

Well, it depends on how much time and effort you are willing to spend to nail this/these bug/s.

IIRC your POCs are interacting via serial lines with the user. There are at least one POC V2.1, one POC V2.0, and probably more than one POC V1.x available.
My first attempt would be to write a script or s.th. similar to drive the two V2 POCs by one POC V1 and to monitor their responses. Aim is to find out whether there is a usage pattern that trigger the crash in a repeatable ("reliable") way. This would help a lot.

Once this is accomplished it should be much easier and finally possible to figure out what is going wrong.


(edited 1x)

[Guus Assmann]

One method that I've once used:
Connect a simple addressable display. (Via the socket of the Eprom)
From the program, write a number to the display.
Depending on the position in the program, the display will "freeze". This shows where the hangup occurs.

BR/
Guus

[BigDumbDinosaur]

BigEd wrote:

If the machine's crash rate is unchanged at slightly high and slightly low VDD, it's more likely to be a digital problem, otherwise more likely to be a timing problem.

Both POC V2.0 and V2.1 behave in a similar fashion, although V2.1 seems to be a little more prone to having its apple cart upset. I have both of them powered off the same power supply, which also has POC V1.1 connected. V1.1 is rock solid. Ergo the power supply is not a likely culprit, which conclusion is bolstered by the five volt output being 5.02 volts.

Although V2.0 and V2.1 are somewhat different designs they share a lot of common elements. Both are equipped with the same amount of RAM, same amount of ROM, both have four serial I/O channels and both use a Microchip (Atmel) ATF1504AS CPLD for glue logic. The RAM and ROM is wired into the system in the same way with both units, and many other design elements are adaptations of what has already been proven in V1.1.

The principle differences between V2.0 and V2.1 are:

1. V2.0 uses a quadruple UART (QUART) for serial I/O. V2.1 uses two dual UARTs (DUART). The pair of DUARTs theoretically contributes slightly more to bus loading.
2. V2.0 uses a basic wired-OR IRQ circuit that is identical to that used in V1.1. V2.1 uses a triple input AND gate to drive the MPU's IRQB input high or low, with each gate input wired to a separate interrupt source.
   

   

   POC V2.1 Enhanced IRQ Circuit

   Not shown in the above are the pullup resistors attached to each of U5's inputs.
3. V2.0's glue logic has five total I/O chip select outputs, one of which is wired to the QUART. V2.1's glue logic has six I/O chip selects outputs, two of which are wired to the two DUARTs.

Comments about timing have caused me to revisit the CPLD code to see if I may have inadvertently set up a race condition that is causing instability. I did see some aspects to the way in which chip selects are determined that could be improved, and ended up doing a significant amount of editing to the logic for V2.0. V2.0 is a better guinea pig for testing at this point because the I/O chip selects are simpler than those of V2.1.

Anyhow, after a number of studying, editing, studying, editing... cycles, I ran simulations on all important logic features, the graphs of which will follow.

By way of explanation, POC V2 has the following architecture:

POC V2 Memory Map

memory_map.gif (8.49 KiB) Viewed 1569 times

At power-on or reset, the memory map exposes ROM at $00E000-$00FFFF—referred to as HIROM, and I/O at $00D000-$00D7FF—this is the default memory map. The "hardware management unit" (HMU), which is a virtual device inside the CPLD that is addressable at $00DFxx (the lower eight bits of the address aren't decoded), can modify the memory map as follows:

Hardware Management Unit

In the above, HIRAM ("high RAM") refers to RAM at $00E000-$00FFFF.

At power-on or reset, all bits in the HMU are cleared, which causes the default memory map to be selected and write-protection of HIRAM to be turned off. Another feature is a write to ROM will "bleed through" to RAM at the same address. This feature makes it possible to shadow the relatively slow (55ns) ROM into much faster SRAM (10ns).

Next, I will present images of the simulations I did on the logic. These will run to several posts, due to the limit on the number of images that can be attached to one post.

Read from "base RAM" at $000000

In the above, a read operation has been performed from "base RAM," which is RAM from $000000-$00BFFF. The read operation starts at vector 19 on the fall of Ø2 (second from the topmost row). At vector 20, the MPU places an address on the bus, VDA goes high and the CPLD reads D0-D3 for the bank bits, which are %0000. So the decoded address is $000000. RAM0, which is the SRAM mapped in from $000000-$07FFFF (512KB), is selected. All of this happens while Ø2 is still low, as the CPLD has a 10ns rating.

At vector 22, Ø2 goes high and the CPLD asserts the /RD (read data) line. RAM0 responds by driving the data bus, which can't be illustrated in this simulation, since it only represents what the CPLD is doing. At vector 24, Ø2 goes low once more and the read operation ends.

Read from "extended RAM" at $010000

In the above, a read operation has been performed from "extended RAM" at $010000. The sequence is identical to the previous, except the bank bits at vector 20 are %0001, which the CPLD decodes as $010000. RAM0 is selected, since the decoded address is in the range $000000-$07FFFF.

[BigDumbDinosaur]

Read from "extended RAM" at $080000

In the above, a read operation has been performed from "extended RAM" at $080000. The sequence is identical to the previous one, except the bank bits at vector 20 are %1000, which the CPLD decodes as $080000. RAM1 is selected, since the decoded address is in the range $080000-$0FFFFF.

Read from "extended RAM" at $0F0000

In the above, a read operation has been performed from "extended RAM" at $0F0000. The sequence is identical to the previous one, except the bank bits at vector 20 are %1111, which the CPLD decodes as $0F0000. RAM1 is selected, since the decoded address is in the range $080000-$0FFFFF.

Read from "high ROM" at $00E000

In the above, a read operation has been performed from "high ROM" (HIROM) at $00E000. When the CPLD decodes the address at vector 20 and determines it is ROM, it will activate the wait-state logic. At vector 20, the ROM is selected and the CPLD's STP ("stop") output is brought out of high-Z and is driven high. STP is wired to the MPU's RDY pin. While STP is in the high-Z state an external 3.3K pullup resistor keeps RDY high.

At vector 22 when Ø2 goes high, /RD will go low, as will STP and, of course, RDY. According to the 65C816's data sheet, RDY will be sampled at the fall of Ø2, which would be at vector 25. The CPLD maintains the state of all outputs under its control until the next rise of Ø2, which is at vector 28. At that time, STP goes high, which drives RDY high, ending the wait-state. The read operation is finished at vector 31 on the fall of Ø2. Also, STP returns to the high-Z state, leaving the pullup resistor to keep RDY high.

Write to "high ROM" at $00E000

In the above, a write operation has been performed on HIROM at $00E000. However, the CPLD logic instead selects RAM0, which causes it to be written at the same address. RAM requires no wait-state, so the write operation is over in one cycle, even though the write is to ROM.

Write to "high RAM" at $00E000.

In the above, a write operation has been performed on "high RAM" (HIRAM) at $00E000. Where this differs from the previous operation is prior to the write to RAM, the HIROM/HIRAM bit in the HMU is set. The HMU setup begins at vector 7 with $00DF00 being placed on the address bus at vector 8. At vector 10, a write to the HMU sets bit 1, which replaces HIROM with HIRAM. Although the HMU is technically in the I/O address block ($00D000-$00DFFF), no wait-stating is required.

Once the HMU has been configured, the write sequence to RAM occurs starting at vector 19, with RAM0 being selected.

[BigDumbDinosaur]

"High RAM" write-protection at $00E000

In the above, a write operation has been attempted on HIRAM at $00E000. However, write-protection was enabled by setting bit 3 in the HMU—also note bit 1 remains set to map out HIROM. Hence the CPLD logic will not assert /WD (write data) signal, which is wired to the SRAM's write-enable (/WE) input, and the write will fail.

Read from I/O device at $00D000

In the above, a read operation is performed on the I/O hardware at $00D000. All I/O hardware accesses are wait-stated, as can be seen in the simulation. I/O device 'A' (IO0, seventh row from the bottom) has been selected. In POC V2.0, that would be the QUART. In POC V2.1, one of the two DUARTs would be selected.

Read from RAM at $00D000

In the above, I/O hardware has been mapped out and replaced with RAM (IORAM) at the same address range. Bit 2 has been set in the HMU (vectors 7 thru 12, inclusive) and therefore RAM is written. Even though the address is in the I/O block, no wait-stating occurs.

Read from "low ROM" at $00C000

In the above, "low ROM" (LOROM) has been mapped in at $00C000 and a read operation is performed. Prior to the read, bit 0 in the HMU is set to map in the ROM. Operation is the same as reading from HIROM.

As an aside, the range $0000-$0FFF in the EPROM corresponds to $00C000-$00CFFF. The range $2000-$3FFF in the EPROM corresponds to $00E000-$00FFFF. The result is LOROM is 4KB and HIROM is 8KB. I'm actually using a 32KB EPROM, so there's some waste.

Write to "low ROM" at $00C000

In the above, "low ROM" (LOROM) has been mapped in at $00C000 and a write operation is performed. Prior to the read, bit 0 in the HMU is set to map in the ROM. However, as with HIROM, a write to LOROM bleeds through to LORAM at the same address. Unlike HIRAM, there is no provision for write-protecting LORAM—that may become a feature in a future design that has a larger CPLD.

[BigDumbDinosaur]

Write & read of HMU at $00DF00

In the above, the last of the simulation graphics, the HMU is written and then read back. The write occurs starting at vector 7 as before, whilst the read occurs starting at vector 19.

As the HMU is a four-bit register wired to D0-D3 on the data bus, D4-D7 are not driven when a read is performed on the HMU. In POC V2.0, that means D4-D7 float during a read. As all PCB traces have some amount of parasitic capacitance, odds are D4-D7 will retain what was last on them. Hence bits 4-7 will contain random values following a read. In POC V2.1, I added a 3.3K resistor array to bias the data lines up to Vcc, which means a read of the HMU will return with bits 4-7 always set. I don't know that it matters either way, but I figured I'd fool around with it and see if anything happens. As both machines exhibit similar issues, I suspect the biasing of the data bus is a "don't care" situation.

In creating the CPLD logic, I did my best to avoid any "gotchas" that are peculiar to the 65C816. All addresses are qualified by VDA and VPA, and reads and writes are qualified with Ø2. This is the same approach used in the design of POC V1.1, which has been 100 percent stable over long periods of operation. So I think I'm on the right track. I attached the CPLD code for POC V2.0 to the end of this post in case anyone wants to have a look and get a laugh.

Finally, the CPLD I am using in both units is rated 10ns pin-to-pin. I do make extensive use of buried nodes, both as logic aggregators and as registers. The wait-state "circuit" uses a D-flop, and the bank bits and HMU are implemented with latches. As use of buried nodes supposedly doesn't add to the 10ns prop delay claimed for the device (at least as I understand it), I believe I have more than adequate timing headroom in the CPLD. However, I also have a 7.5ns version that I will press into service if I continue to have issues after programming the new logic into the existing CPLD.

Code: Select all

/*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*                                                                                 *
*                 W65C816S PROOF OF CONCEPT SINGLE-BOARD COMPUTER                 *
*                                                                                 *
* =============================================================================== *
*                                                                                 *
*     Copyright (c)1991-2018 by BCS Technology Limited.  All rights reserved.     *
*                                                                                 *
* Permission is hereby granted to use, copy, modify and distribute this software, *
* provided this copyright notice remains unaltered in the source code and  proper *
* attribution is given.  Redistribution, in any form, must be at no charge to the *
* end user.  This code or any part  thereof, including any derivation, MAY NOT be *
* incorporated into any package intended for sale unless written permission to do *
* so has been granted by the copyright holder.                                    *
* ------------------------------------------------------------------------------- *
* THERE IS NO WARRANTY OF ANY KIND WITH THIS SOFTWARE.                            *
*                                                                                 *
* While it is believed that all code will perform as intended,  the user  assumes *
* all risk in connection with the incorporation of this software into any system. *
*                                                                                 *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* * * * * * * * * *
* VERSION HISTORY *
* * * * * * * * * *

Ver    Rev Date    Revision
--------------------------------------------------------------------------------
0.1.0  2014/11/25  Original version.
0.5.0  2016/08/16  Added D-block RAM decoding & HIRAM write protection.
0.5.1  2018/05/20  Redesign wait-state logic & reduced wait-state duration to
                   one clock cycle.
--------------------------------------------------------------------------------
*/

Name        glue;
PartNo      B402170001;
Date        2014/11/25;
Revision    0.5.1;
Designer    BDD;
Company     BCS Technology Limited;
Assembly    POC V2;
Location    U2;
Device      f1504ispplcc44;

/*
                                 R    P
                           V  V  E V  H  G  A  A
                  D  R  W  C  P  S D  I  N  1  1
                  1  D  D  C  A  B A  2  D  3  1
               ____________________________________
              /   6  5  4  3  2  1 44 43 42 41 40  \
         TDI |  7                                39 | A10
          D2 |  8                                38 | TDO
          D0 |  9                                37 | A9
         GND | 10                                36 | A8
         IO0 | 11                                35 | VCC
         IO1 | 12           ATF1504AS            34 | A12
         TMS | 13          44-Lead PLCC          33 | D3
         STP | 14                                32 | TCK
         VCC | 15                                31 | RST
         IO2 | 16                                30 | GND
         IO3 | 17                                29 | ROM
             |   18 19 20 21 22 23 24 25 26 27 28   |
              \____________________________________/
                 I  A  A  A  G  V  R  A  A  R  R
                 O  1  1  1  N  C  W  1  1  A  A
                 4  8  6  7  D  C  B  5  4  M  M
                                            1  0
*/

property	atmel {cascade_logic=on};
property	atmel {logic_doubling=off};
property	atmel {output_fast=off};
property	atmel {pin_keep=off};
property	atmel {preassign=keep};
property	atmel {security=off};
property	atmel {xor_synthesis=on};

/*
===============
PIN ASSIGNMENTS
===============
*/
pin     1 = RESB;                                 /* system reset          */
pin     2 = VPA;                                  /* valid program address */
pin     4 = !WD;                                  /* write data            */
pin     5 = !RD;                                  /* read data             */
pin     6 = D1;                                   /* data line             */
pin     8 = D2;                                   /* data line             */
pin     9 = D0;                                   /* data line             */
pin    11 = !IO1;                                 /* I/O device 'B' select */
pin    12 = !IO0;                                 /* I/O device 'A' select */
pin    14 = STP;                                  /* wait-state control    */
pin    16 = !IO2;                                 /* I/O device 'C' select */
pin    17 = !IO3;                                 /* I/O device 'D' select */
pin    18 = !IO4;                                 /* I/O device 'E' select */
pin    19 = A18;                                  /* address line          */
pin    20 = A16;                                  /* address line          */
pin    21 = A17;                                  /* address line          */
pin    24 = RWB;                                  /* read/write            */
pin    25 = A15;                                  /* address line          */
pin    26 = A14;                                  /* address line          */
pin    27 = !RAM1;                                /* RAM chip select       */
pin    28 = !RAM0;                                /* RAM chip select       */
pin    29 = !ROM;                                 /* ROM chip select       */
pin    31 = !RST;                                 /* inverted reset        */
pin    33 = D3;                                   /* data line             */
pin    34 = A12;                                  /* address line          */
pin    36 = A8;                                   /* address line          */
pin    37 = A9;                                   /* address line          */
pin    39 = A10;                                  /* address line          */
pin    40 = A11;                                  /* address line          */
pin    41 = A13;                                  /* address line          */
pin    43 = PHI2;                                 /* system clock          */
pin    44 = VDA;                                  /* valid data address    */

/*
==========================================================
MACHINE ARCHITECTURE & HARDWARE MANAGEMENT UNIT DEFINTIONS
==========================================================

	        +--------------------------+ $0FFFFF
	        |                          |
	        |                          |
	        |                          |
	        |  Extended RAM  (960 KB)  |
	        |                          |
	        |                          |
	        |                          |
	+-------+--------------------------+ $010000
	|       |                          |
	| HIRAM |       HIROM (8 KB)       |
	|       |                          |
	+-------+--------------------------+ $00E000
	        |                          |
	        | Hardware Management Unit |
	        |                          |
	        +--------------------------+ $00DF00
	        |                          |
	        |      D8RAM (1.75 KB)     |
	        |                          |
	+-------+--------------------------+ $00D800
	|       |                          |
	| IORAM |       IODEV (2 KB)       |
	|       |                          |
	+-------+--------------------------+ $00D000
	|       |                          |
	| LOROM |       LORAM (4 KB)       |
	|       |                          |
	+-------+--------------------------+ $00C000
	        |                          |
	        |      BASRAM (48 KB)      |
	        |                          |
	        +--------------------------+ $000000

	             1 KB = 1024 bytes
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  HMU
Register   Address   Register Description   Type  Bit  Function
------------------------------------------------------------------------------------------
hmumcfg    $00DF00   System configuration:   R/W   0   0: RAM at $00C000-$00CFFF (default)
                                                       1: ROM at $00C000-$00CFFF
                                                   1   0: ROM at $00E000-$00FFFF (default)
                                                       1: RAM at $00E000-$00FFFF
                                                   2   0: I/O at $00D000-$00D7FF (default)
                                                       1: RAM at $00D000-$00D7FF
                                                   3   0: HIRAM write-enabled    (default)
                                                       1: HIRAM write-protected
------------------------------------------------------------------------------------------
Notes:  1) Writing to ROM "bleeds through" to RAM at same address.  This behavior will be
           inhibited when writing to HIROM if HIRAM has been write-protected.
        2) The HMU itself is read/write & cannot be mapped out.
*/

$DEFINE   cblkmap   hmumcfg0                      /* LORAM/LOROM control */
$DEFINE   dblkmap   hmumcfg2                      /* IODEV/IORAM control */
$DEFINE   eblkmap   hmumcfg1                      /* HIROM/HIRAM control */
$DEFINE   eblkctl   hmumcfg3                      /* HIRAM write control */

/*
=========================
BURIED LOGIC DECLARATIONS
=========================
*/
pinnode   = [blatch0..3];                         /* bank address registers               */
pinnode   = [hmumcfg0..3];                        /* hardware management unit registers   */

pinnode   = bank0;                                /* 1 = address is $000000-$00FFFF       */
pinnode   = basram;                               /* 1 = address is $000000-$00BFFF       */
pinnode   = bavalid;                              /* 1 = bank address valid               */
pinnode   = cblk;                                 /* 1 = address is $00C000-$00CFFF       */
pinnode   = dblk;                                 /* 1 = address is $00D000-$00DFFF       */
pinnode   = eblk;                                 /* 1 = address is $00E000-$00FFFF       */
pinnode   = extram;                               /* 1 = address is $010000-$07FFFF       */
pinnode   = hmusel;                               /* 1 = HMU being accessed               */
pinnode   = hiramwp;                              /* 1 = HIRAM write-protected            */
pinnode   = ioblk;                                /* 1 = I/O address space being accessed */
pinnode   = iosel;                                /* 1 = I/O device selected              */
pinnode   = mcfgsel;                              /* 1 = HMU configuration being accessed */
pinnode   = ramsel;                               /* 1 = RAM selected                     */
pinnode   = rhflag;                               /* 1 = data fetch on high clock         */
pinnode   = romsel;                               /* 1 = ROM selected                     */
pinnode   = wsext;                                /* 1 = hold bus & control states        */
pinnode   = vab;                                  /* 1 = address bus valid                */
pinnode   = wsff;                                 /* wait-state flip-flop                 */
pinnode   = wsflag;                               /* 1 = wait-state in progress           */

/*
======
RESETS
======
*/
$REPEAT i = [0..3]
    hmumcfg{i}.AR = !RESB;
$REPEND
wsff.AR   = !RESB;

/*
==========================
INTERMEDIATE CONTROL LOGIC
==========================
*/
vab       = VDA # VPA;                            /* true if valid address       */
rhflag    = RWB & PHI2;                           /* true if fetch on high clock */
bavalid   = vab & !PHI2;                          /* true if bank address valid  */

/*
======================
A16-A19 LATCHING LOGIC
======================
*/
[blatch0..3].LE = bavalid & !wsext;               /* open latches, unless in wait-state */
[blatch0..3].L  = [D0..3] & bavalid & !wsext;     /* capture bank, unless in wait-state */
bank0     = [blatch0..3]:'b'0000;                 /* true if bank = $00                 */
extram    = !bank0;                               /* true if bank != $00                */

/*
======================
MEMORY MAP BASIC LOGIC
======================
*/
basram    = bank0 & (!A15 # !A14);                /* $000000-$00BFFF */
cblk      = bank0 & A15 & A14 & !A13 & !A12;      /* $00C000-$00CFFF */
dblk      = bank0 & A15 & A14 & !A13 & A12;       /* $00D000-$00DFFF */
eblk      = bank0 & A15 & A14 & A13;              /* $00E000-$00FFFF */

ioblk     = dblk & !A11;                          /* $00D000-$00D7FF */
d8ram     = dblk & A11 & !(A10 & A9 & A8);        /* $00D800-$00DEFF */
hmu       = dblk & A11 & A10 & A9 & A8;           /* $00DF00-$00DFFF */

/*
===================
RAM SELECTION LOGIC
===================
*/
ramsel    = basram #                              /* select if BASRAM, or... */
            (cblk & (!RWB # !cblkmap)) #          /* LORAM if mapped, or...  */
            ioblk & dblkmap #                     /* IORAM if mapped, or...  */
            d8ram #                               /* D8RAM, or...            */
            eblk & (!RWB # eblkmap) #             /* HIRAM if mapped, or...  */
            extram;                               /* extended RAM            */

/* HIRAM write-protection rule... */

hiramwp   = eblk & eblkctl;                       /* true if HIRAM is write protected */

/*
===================
ROM SELECTION LOGIC
===================
*/
romsel    = RWB & ((cblk & cblkmap) #             /* C-ROM if mapped, or... */
            (eblk & !eblkmap));                   /* E-ROM if mapped        */

/*
===========================
I/O DEVICES SELECTION LOGIC
===========================
*/
iosel     = ioblk & !dblkmap;                     /* $00D0xx-$00DExx if mapped */

/*
================
WAIT-STATE LOGIC
================
*/
wsflag    = iosel # romsel;                       /* wait-state if I/O or ROM & enabled */
wsff.CK   = PHI2;
wsff.D    = !wsff & wsflag;
wsext     = PHI2 # wsff;                          /* 1 = wait-state in progress         */

/*
=================
OUTPUT STATEMENTS
=================
*/
[A16..18] = [blatch0..2] & vab;                   /* A16-A18 address bits               */
IO0       = iosel & vab & !A10 & !A9 & !A8;       /* I/O device 'A' select              */
IO1       = iosel & vab & !A10 & !A9 &  A8;       /* I/O device 'B' select              */
IO2       = iosel & vab & !A10 &  A9 & !A8;       /* I/O device 'C' select              */
IO3       = iosel & vab & !A10 &  A9 &  A8;       /* I/O device 'D' select              */
IO4       = iosel & vab &  A10 & !A9 & !A8;       /* I/O device 'E' select              */
RAM0      = ramsel & !blatch3 & vab;              /* RAM0 chip enable                   */
RAM1      = ramsel &  blatch3 & vab;              /* RAM1 chip enable                   */
RD        = wsext & RWB & vab;                    /* read                               */
STP       = !wsff;                                /* MPU wait-state                     */
STP.oe    = wsflag;                               /* active if wait-stating             */
ROM       = romsel & vab;                         /* ROM chip enable                    */
RST       = RESB;                                 /* inverted reset                     */
WD        = wsext & !RWB & !hiramwp & vab;        /* write, but not to protected HIRAM  */

/*
==================================
HMU REGISTER READ/WRITE STATEMENTS
==================================
*/
[D0..3].oe       = hmu & rhflag;                  /* enable output on D0-D3   */
[D0..3]          = hmu & [hmumcfg0..3] & rhflag;  /* HMU bit pattern on D0-D3 */

[hmumcfg0..3].LE = hmu & !RWB & PHI2;             /* open HMU latches         */
[hmumcfg0..3].L  = hmu & [D0..3] & !RWB & PHI2;   /* D0-D3 bit pattern on HMU */
                   
/* * * * *   E N D   O F   F I L E   * * * * */

[BigEd]

Good to see all that information BDD, it might well help illuminate what's going on.

But for the record...

BigDumbDinosaur wrote:

BigEd wrote:

If the machine's crash rate is unchanged at slightly high and slightly low VDD, it's more likely to be a digital problem, otherwise more likely to be a timing problem.

Both POC V2.0 and V2.1 behave in a similar fashion, although V2.1 seems to be a little more prone to having its apple cart upset. I have both of them powered off the same power supply, which also has POC V1.1 connected. V1.1 is rock solid. Ergo the power supply is not a likely culprit, which conclusion is bolstered by the five volt output being 5.02 volts.

...my point was slightly different. It's not that there might be anything wrong with the power, but that adjusting power as a free parameter is a useful investigative tactic. It's a poor man's Schmoo, if you will. You can learn a lot from a Schmoo plot.

[BigDumbDinosaur]

BigEd wrote:

Good to see all that information BDD, it might well help illuminate what's going on.

But for the record...

BigDumbDinosaur wrote:

BigEd wrote:

If the machine's crash rate is unchanged at slightly high and slightly low VDD, it's more likely to be a digital problem, otherwise more likely to be a timing problem.

Both POC V2.0 and V2.1 behave in a similar fashion, although V2.1 seems to be a little more prone to having its apple cart upset. I have both of them powered off the same power supply, which also has POC V1.1 connected. V1.1 is rock solid. Ergo the power supply is not a likely culprit, which conclusion is bolstered by the five volt output being 5.02 volts.

...my point was slightly different. It's not that there might be anything wrong with the power, but that adjusting power as a free parameter is a useful investigative tactic. It's a poor man's Schmoo, if you will. You can learn a lot from a Schmoo plot.

Ironically, despite all the electronic stuff I do I don't have a variable power supply in my shop. Everything that I've designed has been powered with 3.3, 5, 12 or 24 volts, or some combination thereof. The 3.3, 5 and 12 volt power I get from a (slightly modified) PC power supply. I have a separate power supply I built for producing 24 volts.

Before I tinker with anything else, I'm going to reprogram POC V2.0's CPLD with the thoroughly simulated new code and see if that does anything for me. If not, then it's going to mean digging deeply into the hardware, first looking for the obvious (e.g., bad solder joints) and then the arcane.

[Rob Finch]

Hi, a lot of info to try an absorb.

I note the CPLD is very fast < 10ns and on the graphs the timing is synchronous with phi02. Could it be that hold times are just barely being met ? Would it be possible to insert a few more ns delay on the output of the CPLD ? (another clock cycle depending on input clock ?).