68010 custom computer build

[paulca]

Interesting debug on the ROM programmer.  Helped by claude for number crunching while I feed it copy pasta from datasheets.

Problem:  Spuratic write failures.  Random addresses, clustered in time.  No errors for a full sweep of random write/read/verifies across the whole chip.  Then the next past a cluster of 4 or 5 failed writes, "0xFF" default erase value.

My first test was to lift the board while running error free and stuff my fingers onto every pin I could, really "finger roll it".  Underside too.  Brought the flurescent light down an inch from it and power cycled it.

It didn't flinch or drop a bit.

So I moved to timing.  Asked claude if the delay loop it wrote was tight.  It was.  Did it also include the '245 transsciever switch, drive and settle times?  Nope.

So it number crunched those from the timing table I copy pasta'd to it.  Then it ran a delay loop calibration thing, a gcc builtin? on the STM32F411.  Produced a delay table.  Implemented.

Still a cluster of errors only 25% through the first sweep.

So I told it to leave the documentation for those delay values in place and state that we doubled them for engineering grace.

Still no errors this pass.  However.  It's now, both chips, full 512Kbyte 0x80000 write, read cycles x2 chips.  Its not at all fast.  Like 15-20 minutes per full write. 

Part of my doesn't care.  It will be a while before I need a ROM anywhere near that size, but part of me thinks the timing, somewhere, is bogus.  Like a stupid HAL_Delay(1) hiding.

[paulca]

68k ROM flash CLI ready. Type 'help' for commands.
Sweep 1: erasing...
Sweep 1: PASS (0x80000 addresses x2 chips)
Sweep 2: erasing...
Sweep 2: PASS (0x80000 addresses x2 chips)
Sweep 3: erasing...
Sweep 3: PASS (0x80000 addresses x2 chips)
Sweep 4: erasing...
Sweep 4: PASS (0x80000 addresses x2 chips)
Sweep 5: erasing...


Sums up how my evening went.  If only it didn't take 30mins per test.  Then again, this is absolutely worst case.  Each byte is a write, then read, low chip, then high chip.  Single threaded.  Writing a straight block and verifying a straight block has WAY less timing delay involved.

[paulca]

Feet dragging time again...

I have this routed with 0 warnings DRC/ERC, could use a bit of labelling on the silk.  Its a fully SBC bootable computer.  5V CPU, 3v3 everthing else.

But...  I'm procrastinating now.  The board has ZERO input or output except the IDC headers which exports an 8bit IO bus. 

Im basically setting myself up to debug a blind, headless PCB.  If it works and I attack something to that IOBus it might say "Hello world", but if it doesn't work.  Its going to be formidable to work out why.

As a minima if it's "going to press", I need to add as many test points as the route will permit.  They will be scattered to the 9s but there is plenty of room around to route edges if I can catch signals in the open for a test point.  The header itself covers a good 75% of important test points.



Period UART is already out.  The board is firmly 3v3 beyond the CPU and I spent a lot of time and effort ensuring that.  So it's a 3v3 UART ... or I2c... or SPI.... or why not an STM32F411 doing all of the above on that io bus?  Because none of that part is tested yet.  The FPGA in circuit is deliberately small and deliberately only there so I can get a few mistakes in the address glue and DTACK timing without a board respin.   It does not have the IO to run a UART.

I want to get this board "Out of the way" as it's blocking the 'real' board building, as it tests a lot of things in concert.  If they work, the board basically gets cut in four.  CPU+Transciever on one PCB.  Memory/FPGA on a Memory card.  Powersupply and bus pulls on the interconnect/backplane.  Then I can add as many IO cards or experiements as I like.

[paulca]

So this arrived.



2 hours of placing and abracadabra:



In review.  Those RNetwork footprints provide zero margin for error.  Like none.  When placed the castled edges barely touch pads on both sides.  Some did not make bond on both sides, but most did.  The FPGA looks like it doesn't even need touched up or reworked.  The LVC level shifters I can see are going to be a pain as always.

Just a coupled of caps which escaped solder paste somehow and the through hole stuff to go.

[SiliconWizard]

I was just thinking - do you have a means of uploading code to RAM without having to re-program EPROMs? That sure would make development much easier.

[paulca]

I was just thinking - do you have a means of uploading code to RAM without having to re-program EPROMs? That sure would make development much easier.

Its the immediate goal after it boots, but it needs the IO header and the IO board is still in KiCAD.

The most this board is going to do is light LEDs on the IO header to tell it's booted or not.

For V2, it going modular, but the memory card won't have any ROM.  It will just have the FPGA memory "controller" contain a bootloader and enough for the CPU to go get it's boot code from an SDCard or similar "disc" surrogate.

[paulca]

So I reworked the bridges and fixed up the RNetworks. 

The RNetworks are a ___ing curse.  I am changing that footprint for any future use of these, even if it means I can't sneak a via between the pads.  The actual package is about 0.2mm wider than the space between the pads.  If the placement is off by 0.2mm only one side "flows" onto the pads.  It took me an hour to fix them all an I had to resort to some rather janky techniques.  Like "skating them around with the iron until they got aligned and then holding them down with tweasers ... all while the solder was flowing. 

I tried removing them, cleaning it up and hand soldering them but there was just not enough area to even "tack" them down.  The moment you touched the other end it would twist out of alignment.  I tried removing, cleaning up, applying solder paste by hand and air reflowing them...  Not a hope in hell.  They just pulled to one side or other because the air couldnt get both side flowing at exactly the same time.    They are not pretty.

I may have screwed up the footprint, but I was sure I download it from Digikey.  Then again I suppose they are not only in error sometimes, but in others they give NO tolerance and expect machine placed, machine pasted and oven soldered.  0.2mm placement accuracy is a given.

On the other hand.  The many bridges on the LVC transcivers came out with just a touch of the iron.  Only one needed a blob removed with wick.

[paulca]

It powers up.
The FPGA is flashable.  Blinky worked.  Real bitstream flashed.

I put the CPU in it and powered it up.  Current limit instantly.  But it was set to 40mA.  It took 220mA to be happy.

And... first impressions where, "It's inert".  Damn.

So I got the meter out and went looking.  First checks, the bus state.  "Word Read" waiting on DTACK.

Hmm... So the FPGA isn't answering DTACK... bummer.

Then I turned the oscilliscope on and looked closer.  Epic!

The CPU did exactly what was expected with no ROM chips installed it shot straight through ROM and hung on something random in the SRAM.

I was expecting the FPGA's LED to even flicker, but nope.  It comes out of reset and is off the end of memory in milliseconds.  Might need to latch them.
 
I'm having a beer in celebration and will consider my first test ROM tomorrow!

[paulca]

So it was all going so well up until it wasn't.

The CPU is not reading what is on my ROMs once inserted.  It's reading something, but not sure what or where from.

I did find "a bug" and it is a show stopper (requires PCB surgery rather) and I got excited I'd found the fault, then I realised it can't be the "only" one.

The first bytes of my ROM are:

0020 0000

Setting the supervisor stack pointer to $200000 - top of RAM.  I can only see the lower 8 on the logic analyser, but I expect to see the "lower 8" of 0020 = 20.  Bit 5 high.  I don't.  It gets "0000".  But not all memory addresses are reading 0x00, lost of it isn't.

The bug I found was that during routing, I flipped D0-7 and D8-15 for routability.  This is fine as the flip happned on both sides of a transciever, teh 1 to 1 pairing intact.  What was NOT flipped were the drives for those two banks.  So  "UDS" asserted drives the lower 8 bits and vice versa.

The reason this can't be the only bug is... the first reads from the CPU are "both" UDS+LDS and so under word reads it's irelevant.  It can't make it not read the lower 8 as 0x20.

The UDS/LDS swap.  I can't fix it in firmware or in code or in how I flash the ROMs.  If the CPU wants the lower 8 and drive LDS low, the upper 8 will drive and the CPU will read nothing on the lower 8.  Even if I swap what memory chip is active under LDS, it wont matter.  The good news is... the tracks/pins in question have multiple plausible surgical intervention points where a cut and swap is possible.

But it's not the only bug and so the hunt continues.

[paulca]

Oh.  It's already drawn blood now.  No tears yet.

I ordered double height header pins so I could connect the female dupont logic analyser leads to the female board header.  Only I ordered ones with he black holder at one end.  It was the only ones I could find in a rush and I figured... they usually pull out of those anyway, I'll just push it into the midpoint with pliers.

This did not work.  These ones cruely are well secured and would not move.  So I attacked each pin separately.  Pulled it out, then slid it back in just enough.

The first one to slide back in, good pound of force or so with the pliers....   disappeared into my finger.  The side of it where there are less nerves.  A good 3 or 4mm of the pin header disappeared inside me.  No pain.  I just pulled it back out and hoped there was nothing nasty on it.  It bled.  Seems to be healing and not getting angry or infected... yet.

Pin headers might look innocent, but trust me, this is not eh first time I have stabbed myself with them.  The classic is putting force into pushing a Dupoint into subission and your finger slip off and land on the pin head beside it.  STM32 Nucleo boards seem designed to induce this exact injury.

Its a general lesson of using any scale of tool, isn't it?  If you are applying 'excess' force, consider the failure modes where that force gets used against you when you slip.  "Cut away" from yourself.  Consider a vice.  Etc. etc.

[paulca]

Its executing code at last!

It is supposed to be my boot rom from emulator, I can trace it a bit with only 8 address lines and 8 datalines, but I get lost.  Either way it ends up in a lock loop suggesting a failed "self test".  If anything fails during test, like a memory write/readback test, it will jump to an inflinite loop.



EDIT:  Having fixed the bit decode in the logic analyser to be better, ie. it's Address 1-8, not 0-7.... the dissassembly was much easier and ... it failed because I did not write the sentinel at the end of ROM... as programmed to.  That means it works!  Well....  that is quite early in the "POST" before it tests memory writes etc.  So still room for failure.

[brucehoult]

When some friends and I designed and built a wire-wrapped M6809 machine in 1983 nothing appeared on the console (attached to a VT100) and we only had a 2-channel analogue (of course) oscilloscope to debug it with. One channel for the clock, plus one data or address pin at a time on the other channel ... worked ok in a tight loop.

The first problem was that it was constantly fetching the reset vector. Turned out we'd wired the reset switch to the NC terminal not the NO one. Oops.

The second problem was garbage appearing on the VT100. The code was just trying to output "Hi!\n" in a loop. The trace of address fetches looked fine, but garbage out. Turns out we'd wired the baud rate divider for divide by 12 not the needed divide by 13. (baud rates are weird submultiples of 1, 2, 4 etc MHz)

There were no more problems!

[paulca]

This thing is fighting hard trying not to work.  It's throwing everything at me.  So far:

FPGA async logic (yes, yes, yes, I hear you groan) DTACK logic was ... "works perfectly in simulator".  Claude helpfully double clocked the signals and that start things working in silicon.

Next LDS/UDS were found swapped on the transciever.  Surgery fixed.  I got really lucky and those drive pins are the end pins on the SSOP48.  A botch wire and a careful track cut was successful.

The board then kept just being "Weird".  It would start, run, crash and refuse to reset.  For a while it got ignored as it had guenuinely crashed for other reasons by that point anyway.  However, when it entered a crash loop of "jmp *" 10 seconds later I would noticed it had just "stopped".  No bus activity.  Dead. 

Then I noticed ... it depended on where my hand was when I pressed RESET as to whether reset worked or not.  "I smell a floater!"  Located to be TWO pins, not one.  Not exactly "innocent pins" either.  LP0 and BERR!  Floating noise on either of those = insane CPU.  The bank of pull ups all measured 4.7k to 5V except those two with 10+MOhm.  So that fixed.  Those same footprint issues with the RNetworks.

Then getting closer.... A20 was glitching in and out on the logic analyser.  The scope showed it was perfectly in sync ... just 1/2 rail.  "I smell a bridge!"  Resoldered the ... you guessed, F'king RNetwork pull down.  A20 solid again.

Now I am diagnosing a lazy databus settle.  Suspecting ... guess f'king what?  RNetwork pull ups on the RAM signal lines.

At one point I was eye'ing up the 0805s and ondering if I could solder 8 of those in the same space, but sadly no.  Long enough, but too wide to fit 8 not shorted.

I am literally going to print that foot print out and ceremoniously burn it.... then delete the file and meausre the next one by hand.

i started this moring at 8am.  It's 2pm.  Time or a nap.

[paulca]

Another observation now Im buried in the nanoseconds for the moring...

Pull up/down on the LVCMOS side for things like "DBus"... are a bit pointless if Im honest.  They do not behave like I expected, nor do they need to.  The RC time on a 10K pull up/down is hundreds of nanoseconds.  It is not going to do the slightlest thing to datalines between bus transactions.  You will not see them all snap to 0 for example.

The 4.7k pull UPs on the CPU side are there for a different reason, more to help the NMOS give a convincing HIGH output.

[paulca]

Finally, it completed POST/BIT and polled for it's UART status=TXRDY ... forever waiting to say hello.

The BIT test did fail for valid reasons.  The forced address error I threw in emulator land has the short 68000 exception frame.  The real 68k spits out 32 words of data, which failed my test.  That test disabled and the rest completes, even the RAM probe to find whats installed... which is pointless as I know!  You gotta have a mem check though, right? 

The rest of those BIT tests came in exceptionally handy today.  I was able to see it locked in a "jmp *" scroll back in the analyser using the lower 8 bits of address to work out which path it ended up there via.  What was it doing before it went there.  All traced back to lines of ASM and specific test failures.

[SteveThackery]

This has become an epic tale of our hero overcoming adversity. 😄

[David Hess]

Pull up/down on the LVCMOS side for things like "DBus"... are a bit pointless if Im honest.  They do not behave like I expected, nor do they need to.  The RC time on a 10K pull up/down is hundreds of nanoseconds.  It is not going to do the slightlest thing to datalines between bus transactions.  You will not see them all snap to 0 for example.

That may be done to create a valid logic level when the bus is not driven.  Otherwise with CMOS inputs, the bus may settle midway, causing both input transistors to conduct and overheat if this continues for too long.

[SiliconWizard]

Pull up/down on the LVCMOS side for things like "DBus"... are a bit pointless if Im honest.  They do not behave like I expected, nor do they need to.  The RC time on a 10K pull up/down is hundreds of nanoseconds.  It is not going to do the slightlest thing to datalines between bus transactions.  You will not see them all snap to 0 for example.

That may be done to create a valid logic level when the bus is not driven.  Otherwise with CMOS inputs, the bus may settle midway, causing both input transistors to conduct and overheat if this continues for too long.

Yes, that's likely. Even if the corresponding rise/fall time is relatively "long", it's well enough to avoid excessive power draw and heat during "all hi-z" situations. Those inputs may not have schmitt triggers (to be checked though).

[paulca]

I added them.  "If a line can tristate, pull it" was the rule.  I just noticed on the logic analyser, the CPU doing a "High" read D8-15 ... D0-D7 did not contain all zeros.  Yet they are pulled down with 10Ks.  So I considered the RC time and thought, "Ah..."

So the logic analyser is great, but it doesn't make a very good interface.  So this is now sitting in the "Sleep on it" out box.

3D model of the IO board concept.  MCU does the actual IO and the FPGA does the bus stuff the MCU is possibly too slow for.


I really do need to go USB-C.  Not least those are cheap USB-B micro sockets and they routinely bind up... or inhale solder and not work.  I was  daunted by USB-C footprints, but I think i get the jist and I only need DP,DN and CC1/CC2 resistors if I want power.

Power on this is either via the "system" 3v3 on the header or a 3v3 regulator from VBus for bring up in isolation.  When the VBUS derived 3v3 is selected out I left it with a 47k resistor to give it someting to do.  Probably pointless.

[paulca]

The way I hope to get the IO to work.

The FPGA matches the IO address region, nAS, LDS to the IO Region and uses RnW to determine what to do with the databus.

READ: Data towards CPU. 
FPGA asserts "MCU_ENABLE".
MCU reads the address bus etc, determines what to do, drives the databus to the FPGA and asserts "MCU_IO_DTACK".
FPGA latches the data, drives the real databus and "Edges" IO_DTACK to the main CPU board.
The main CPU board relays IO_DTACK->nDTACK.  (Only one driver on nDTACK.  One state machine.)
The MCU sees IO_DTACK and HiZ's it's databus as quickly as possible, then releases MCU_IO_DTACK.

Threeway 'ack' for reasons.


WRITE: Same as above but with an extra step.
Because  READ/WRITE/READ/WRITE can happen back to back in rapid succession, the FPGA has to wait on MCU_IO_DTACK being deasserted.    If the last transaction was a READ the MCU may still be driving the databus.  So thats why the third handshake (MCU_IO_DTACK releases) is there.  When it's released it can drive the data at the MCU and assert MCU_ENABLE.

Interrupts is where it gets interesting.  The FPGA has no visibility over interrupts.  The MCU does.  It has IPL0-2 it can pull.  It also has the FC0-2 pins to determine an interrupt ACK.  Lower address for "which priority" and so... in theory an Interrupt Acknowledge looks to the FPGA like a standard "IO Read" - by pure luck my IO space is 1111xxxxx....  and asserts MCU enable as normal.  The MCU can determine it's an INT_ACK and drive a vector onto the databus.  The read transaction completes as normal.

"In theory".  There is the case of other "CPU Space" states with very similar signature to double check.  Some of them signal their type with the middle bits of the address, which is awkward as my IO board has none.  So a "not an INT_ACK, but looks like one", could cause issues to the above.

[paulca]

If any kind sir/madam has 2 minutes to cast an eye over this for obvious dumbness I would appreciate it.

Excuse the scattered pins, but it was mapped for routing, both main ICs are "soft mapped" in firmware.

EDIT:  Power considerations.  The main CPU board, without the 5V CPU socketted pulls about 15-20mA.  Most of that is LEDs.  The 3v3 regulator is rated for 250mA.  So it should be fine powering both boards stuck together with headers.  Most of the load on the CPU board comes from the 1970s CPU, pulling a good 200mA!  It's straight from the bench PSU.

[paulca]

Some claudage produced me this spec for the current FPGA address glue firmware.  It can be handy for this, as well as "Can you add all the comments I was too lazy to add to this assembler?"

What amuses me.... with async 74HCT combination logic you can assert DTACK ... shit I could tie it to ground and it would work.  The only reason it got more complicated is because of IO and future bus experiments require I have wait states at all.

So it got to "a few too many gates" to not make a mistake and I added an FPGA.  The FPGA took one look at my async combinational DTACK logic... worked perfecty in simulation.  Worked most of the time on a protoboard test and oscillated insanely on a PCB...

I added double clk synchronisers to the signals.... and guess what.  Now the timing on the ROM is marginal. 

Did the FPGA just make things "slower"?  Thats not meant to be what it does, right?  Bizarre, bizarre.  Slower, but far more deterministic, literal and precise about the correct order of things.  Which should do me well later.

Eventually I'll put the git repos on the public gitlab where you migtht be able to see this with 2020s era auto formating UI.

Code: [Select]

address_glue — Firmware Datasheet
68000 async-bus glue logic: decodes CPU address/control lines into ROM/RAM chip selects and OE/WE, and generates correctly-delayed DTACK.

Target: ICE5LP4K-SG48ITR (iCE40 LP4K, SG48), custom PCB. Clock: internal SB_HFOSC, undivided → 48MHz ±10%. All internal logic is synchronous to this clock; the 68000 bus is fully asynchronous to it and is double-flop synchronized on entry (2 clk latency) before decode. CPU bus: 68000, 8MHz.

Pinout (address_glue.pcf)
Signal Pin Dir Active Notes
in_ctl[0] nUDS 44 in low upper data strobe
in_ctl[1] nLDS 42 in low lower data strobe
in_ctl[2] RnW 45 in high=read
in_ctl[3] nAS 43 in low address strobe
in_addr[3:0] 46,47,48,2 in — top 4 address bits (region select)
out_bus[0] ROM_L_nCE 34 out low
out_bus[1] ROM_H_nCE 37 out low
out_bus[2] RAM_L_nCE 35 out low
out_bus[3] RAM_H_nCE 38 out low
out_bus[4] MEM_nOE 32 out low shared ROM/RAM output enable
out_bus[5] MEM_nWE 36 out low shared ROM/RAM write enable — ROM side wired but must never be driven; ROM is read-only by design, not by decode
nDTACK 12 out low to CPU
IO_DTACK 18 in low=trigger external DTACK request, ORed in raw — bypasses the wait counters below entirely; anything driving it must already be correctly timed
led_red/green/blue 39/41/40 out low=on status RGB, see below
out_bus/in_ctl must stay declared [5:0]/[3:0] (not [0:5]) in every module along the chain — a width-matched but bit-order mismatch silently cross-wires every pin (see git history: this hit real hardware).

Address decode
ROM selected: in_addr[3:0] == 4'h0 && nAS==0
RAM selected: in_addr[3:0] == 4'h1 && nAS==0
Either qualified further by nUDS==0 || nLDS==0 (a strobe must be present) before chip-select/OE/WE or the DTACK counters below start.
DTACK timing
Each region has its own saturating wait counter (ROM_DTACK_DELAY, RAM_DTACK_DELAY), started when that region's chip-select/OE go active and sized against real device timing (ROM ~70ns, tRC-decoupled/not trustworthy to the ns; SRAM 55ns) plus the 68000's fixed DTACK sample point (S4/S5 edge, 1.5 CPU clocks after AS):

Region *_DTACK_DELAY CE/OE→DTACK Reads cost Writes/RMW (incl. TAS) cost
RAM 2 ~72ns 0 wait states 1 wait state
ROM 6 ~156ns 1 wait state 2 wait states
Writes/RMW cost one extra wait state versus reads on the same region: the 68000 delays UDS/LDS by a full CPU clock (125ns) on those cycles, and since our counters key off the strobes (not AS), that CPU-side delay and the internal margin shift together in lockstep — reads/writes on a region always differ by exactly one wait-state tier, with matching margin. TAS's write phase is the known-fragile case on real 68000 silicon — retest specifically after any change here.

DTACK is never asserted early/optimistically: it only fires once the counter reaches threshold, never on the same edge chip-select goes active.

Status LED (status[2:0] → RGB, negative-logic drive)
Bit LED Meaning
status[0] blue MEM_DTACK asserted
status[1] green AS asserted (cycle in progress)
status[2] red write cycle (~RnW)
Build/test
make test — iverilog/vvp testbench (address_glue_tb.v)
make all — yosys/nextpnr-ice40/icepack → address_glue.bin
make prog — flash via DIY STM32 SPI programmer (no onboard FTDI/JTAG)


[paulca]

Jumping into the future "for real" modular design today.

The function of a "Debug/Monitor" "card" came up.  It was the first in what I am sure will be a queue of "Which CPU signals do we intervene with?"

DTACK springs to mind.  I am still undecided as to whether DTACK itself should be "managed" by the backplane or CPU card and other "DTACK Request" lines provided to produces of it.  Then it's my control who and when DTACKs.

A simple blunt mechanism would be to put a NOR gate on DTACK.

nDTACK_BLOCK NOR nDTACK = CPU_DTACK

Keep nDTACK BLOCK pulled low.  nDTACK is transparent.  But when the debug card wants to halt or step the bus, it can pull the BLOCK pin up.

Its basicaly a 2:1 mux.

A similar feature in consideration is to make all the CPU transiever drive pins also "MUXed" with backplane signals.  Defaulting to just "pulls" and transparent, CPU drives, bus drives.  But... pull the block signal and the CPU is muted (and blinded).  Completely unaware it has been, but if done at the right time, it can be umuted and resume without knowing any better of it.

The thing is though.  Using 96 contact connectors in 3 rows.  It's very appealing to make the middle row GND+PWR and leave the outer rows signal only.  That makes it exportable via ribbon cable into protoboard or even breadboard.  I am already down to 4 pins or I need to break that rule.

[paulca]

Another application of AI...  I had tested the PCB to the point it passed my tests and awaits an IO board.

But I asked claude for an overall  review and somethings were tidied up. 

Then I asked it to write soak test and let me torture the build for a few hours.

It produced a MEM_TEST assembly which writes all of RAM  value=address type sweep.  Then reads all of RAM back.  Then it repeats using byte only. long words, etc. etc.  Then it runs a full RAM sweep of "TAS" test and set operations.

I let it run for a few hours.  Apparently no errors.  If the test failed it would jump to an IO address causing a bus halt on my hardware right now.  It didn't get there.  The FPGA decode LED showing bus states alternated between "White" - writes included and "Cyan" READ and DTACK only.

Its interesting to reflect on the 68010 getting nice and warm... that chip may never have been online and warm in it's 40 year life!   It could be old stock or reclaimed.  Either way, it's been a long time since it was awake and warm.  So running that test for a few hours was worth doing.  Then I let it cool and checked it still ran. 

Seems its "stable"... dare I say it... for now anyway. 

The logic analyser traces at 100Mhz reveal something I almost did not account for, but the FPGA double clocking of signal negates neatly.  The bus transceiver drives are directly driven by the CPU.

A normal bus transaction starts by the CPU settling it's address lines and then asserting AS Address strobe.  Howerver on the 3v3 side of my board the address lines only begin to settle when AS is asserted and powerup the LVC245.  Similar happens for the databus during a write.  The Logic analyser configured to bus rules on "AS" marks most writes and every other address as "X" for "Changed under enable".  It basically adds 10-15ns to the settling time, beyond AS, nothing to worry about, but the LA is correctly(?) expecting Address and data to be stable while enabled (AS) is active.

The deassertion of the databus raised a concern, the CPU will lift UDS,LDS and thus the datadrives at the same time.  The databus will float against 10K pulldowns momentarily while it's WE/CE are still active for those two FPGA clocks.  However.  They are clearly stated to latch on the falling edge.  Rather than rely on that I made the deassertion by datastrobe immediate.  Not double clock syned.  This was all done before the multi-hour soak test.

The more interesting thing to me anyway.  The Logic analyser only sees the 3v3 side of the board.  So all it's signals are delayed by the transcievers.  How then can it see transient states?  Its because of the different delays from the bus transciever.  Control lines are drive by "! RESET", address lines and datalines are driven by the CPU bus states and the OE has a much longer delay than a transparent passthrough change.

[paulca]

So the IO test board PCB arrived.  Soldered it up and so far it does dual blinkie.  This at least confirms the FPGA and MCU are programmable and the LEDs work.



Tomorrow I'll start tackling a proviing out setup on both.  ie.  test firmware and bitstream to have them test the interconnect lines.

I don't think I need to test the header   So that means by Thursday the board should be mated with the CPU board... which should in theory boot straight to "write TX_EN=1 to the UART1 config register".  Step one being the FPGA correctly identifying that and uses an LED to signal such.  Then the MCU enable and data transfer... and so on and so forth.

ERRATA so far:  The 100n anti-bounce cap goes across the RESET switch, not to ground on it's own.  Doh!    Fixed by shorting said cap.

The soldering... I bought T5 small ball paste, Quickchip.  This was a manually pasted board.  The paste flows better when manually applying to pads, almost too well, it can get carried away and you need to be careful starting the flow or it will begin to flood with momentum or "sprng" in the syringe pressure.  On reflow it was not much better than the T3 standard stuff to be honest.  Similar amount of bridging.

The STM32 required debridging but it went quickly.  The FPGA was "dead on arrival" and close inspection revealed dry pins.  I did a full hot air reflow on it with flux and a redrag making sure to press into the leadless contacts, you can feel them scrape the iron if it's right.  If you don't contact them, it seems pulling the iron away can suck the solder out of the contact on and along the pad leaving the joint dry.

ERRATA No.2:  The decoupling cap for the SPI Flash chip is in a different postcode.  It works, but be careful next time.

That RGB LED is a mean bit of kit.  Cree of course.  While checking "pin 1" in the datasheet, I noted it says, "WARNING: DO NOT look directly at the exposed LED in operation.  Eye injury can occur".

I think it's meant to behind a diffuser or light pipe.  I run it with the LED drive on minimum, but on full power, it will burn your retina and is rather unpleasant.  Lights the room!  I think the video above is it on minimum!

It reminds me of the Cree strobe like I bought for the drone.  It powers on in "safe" mode and gives you a false sense of security as it's pretty tame.  Then you click the button one more time and BANG... blinded by the first white strobe pulse.  Thats what it's meant for.  To make the drone visible from a mile away at night.  Even has a full nav mode.  The red and white flash the correct "anti-coliision" light and strobe light sequence and shne red one way, green the other.  From a distance it will look like an aircraft red anti-collision light and white strobe to attract attention, with a hint of solid green or red or both depending on where you are.  So not only does it "appear to be something", it will possibly ID as an aircraft to someone looking for one and even what direction it's facing.