Email or username:

Password:

Forgot your password?
Top-level
Tube🍂Time

there's a glitch! that's why I missed it before, it's only 2ns. this is the signal from the MCA bus clock domain, and it's getting picked up in my other clock domain's edge detector.

35 comments
Tube🍂Time replied to Tube🍂Time

and i believe this is the cause. this line right here. each signal, la_*, is an output from a flip flop latched by the micro channel bus cmd line. however, this line of code creates some combinational logic--there's a timing hazard here...

Tube🍂Time replied to Tube🍂Time

the problem? the line (la_addr == REG_ATN) creates a bunch of gates that are slightly slower than the simple AND gates in the previous part of the line.

so la_mca_op=1, ~la_s0_w_l=1, and (la_addr == REG_ATN) *is also a 1 for a very short time!!!* this is because the previous value of la_addr WAS a REG_ATN.

what i need to do is take that entire wire and turn it into a latch (a reg) and clock it on cmd.

Tube🍂Time replied to Tube🍂Time

so here's the solution: all the signals in the MCA bus domain go to a latch clocked in that domain (the first "always" block).

then *without any combinational logic* the output of that latch goes *directly* to another latch (the second "always" block) located in the main clock domain.

(i have another flip flop in main clock domain just for detecting the edge)

Tube🍂Time replied to Tube🍂Time

next step is to optimize the interface speed. right now it takes 25us to read a sector from the SD card but ~5 milliseconds (ouch) to DMA it to the PC!

it's mostly an issue with the Teensy-to-FPGA interface, which is async and simple: 4 address lines, 16 data lines, a read control line, and a write control line. everything else is done as a register in the 4-bit address space. flag register for status and mailbox sync bits.

Tube🍂Time replied to Tube🍂Time

why is it 5ms per sector for DMA? well, it's about 20us per word. most of that time is wasted by the slow interface between the Teensy and the FPGA. I really should fix that.

Tube🍂Time replied to Tube🍂Time

got rid of some delays and now we're down to 6us per word. but there are some unexpected wide gaps in between transfers between the FPGA and the Teensy.

Tube🍂Time replied to Tube🍂Time

ahh that must be the issue, when i change from a read to a write, i have to set the port direction for 16 IO pins. pinMode is uhh not quick, so let's try writing to the port direction register directly.

Tube🍂Time replied to Tube🍂Time

that's better, it's 2us per word now.

Tube🍂Time replied to Tube🍂Time

so how does this compare with the real drive? it transfers a word in about 1.6us (compared to 2us for mine), so it is slightly faster for sustained data transfer with data that fits in the internal buffer. however, seek times (in the ms range) more or less cancel this out.

Tube🍂Time replied to Tube🍂Time

here's a DMA cycle for the real hard drive. it's using the bus more efficiently, requesting a new transfer as soon as the transfer completes. my design waits for the full DMA cycle to end before requesting a new one.

Tube🍂Time replied to Tube🍂Time

maybe theoretical maximum transfer rates would make the comparison easier:
My drive: ~1MB/s
stock HDD: ~1.25MB/s (neglecting seek)

if i put in a bunch of work and implemented burst mode DMA transfer, i might be able to hit 4.5MB/s.

Tube🍂Time replied to Tube🍂Time

no more debugging wires. the DBA-ESDI drive is now running stand-alone!

Tube🍂Time replied to Tube🍂Time

I printed an angled carrier. the angle is because the socketed Teensy is really tall.

Tube🍂Time replied to Tube🍂Time

time to lay out a version of this board for other PS/2 models, like the 50Z. this is the somewhat less uncommon 72-pin DBA-ESDI form factor.

Tube🍂Time replied to Tube🍂Time

well that was a bit tricky, but it's more or less laid out now.

Mike Grusin replied to Tube🍂Time

@tubetime Nice! (And LOLing because I JUST asked a client whether they really need the big teensy or could they go with the smaller one.)

doragasu replied to Tube🍂Time

@tubetime Reading the silk screen of your boards is always so much fun! 😂

Tube🍂Time replied to Tube🍂Time

looks like there's a rare problem when reading sectors, around 1 in 100,000 reads. ugh these can be hard to track down

Tube🍂Time replied to Tube🍂Time

i thought it might be a timing issue caused by disabling USB debugging, but it still happens (with roughly the same statistics) with USB debugging turned on.

Tube🍂Time replied to Tube🍂Time

looks like some individual data bits are getting flipped. what's really odd is that it is repeatable and it seems to be the same bits at the same addresses.

Tube🍂Time replied to Tube🍂Time

also -- there seem to be two overlapping bugs. one causes a few bits to be corrupted for single sector reads, the other causes an entire sector's data to be shifted by several bytes.

Tube🍂Time replied to Tube🍂Time

huh, once I connect the logic analyzer, the problem takes much longer to reproduce; the probability of data corruption drops dramatically. interesting but it makes things much harder to debug.

/dev/rdsk/c5t1d0s2 replied to Tube🍂Time

@tubetime hey @azonenberg weren’t you looking for examples of probes changing behavior of the DUT?

Tube🍂Time replied to Tube🍂Time

looks like it is skipping a transfer here somehow. it transfers B66D, then it skips 6DDB and goes to DBB6. the preempt line seems to deassert right before arb/gnt goes high. that doesn't seem right.

Jon Dubovsky replied to Tube🍂Time

@tubetime A coincidence that DBB6 == 6DDB << 1 ? Could it be slipping a bit?

Tube🍂Time replied to Jon

@jond no that is just the pattern in the disk image. presumably a disk area that was never written to after being formatted and still contains this bit pattern.

Tube🍂Time replied to Tube🍂Time

the smoking gun: an invalid bus transfer. both rd and wr are asserted at the same time. before that we see the missing data on the bus: 6DDB. so the card thinks it is in a DMA cycle even though it is not, and it's putting data on the bus when it shouldn't be!

Tube🍂Time replied to Tube🍂Time

i deleted 3 characters from my verilog and it works now. 😅

(i still need to test writes, and i need to test it without the logic analyzer card)

Eric Carroll replied to Tube🍂Time

@tubetime As the joke goes, its all about knowing where to tap...

Michael Kohne replied to Tube🍂Time

@tubetime Ugh, that's NEVER good. I see lots of oscilloscope probing in your future.

Tom replied to Tube🍂Time

@tubetime I like your part naming convention! 😅

1000millimeter replied to Tube🍂Time

@tubetime Why is there a SD Card slot forseen on the baseboard as well?

Tube🍂Time replied to 1000millimeter

@1000millimeter in case i want to use a soft CPU core in the FPGA instead of a separate Teensy

Go Up