[Cryptech Tech] dev-bridge board

[Paul Selkirk]

I've been working with the dev-bridge board for the past week or so, and
here's where I'm at.

1) The Novena high-speed expansion connector is sensitive to position,
and the large dev-bridge board tends to rock on it, which can cause
problems talking to the FPGA. The board has two mounting holes, aligned
to holes on the Novena. It seems prudent to attach the board to the
Novena with approx 4mm spacers, to hold it in correct position. (5mm is
just a little too big, so back to the hardware store after lunch, or
scrounge up a stack of washers.)

2) There is a known problem with address bit 19 (connector line
FMC_A17), which causes it to consistently fail the fmc-test. [Aside: The
ARM has byte-oriented addressing, but the FMC driver does 32-bit writes,
so we don't even have address lines for the low two bits of address.
Which is why we're talking about address _bit_ 19, but address _line_
17. Just so we're clear on that.]

Fredrik explains the situation thusly:
> Ok, so we more or less have a confirmed weakness in either the Novena
> board/connector or in the dev-bridge.
>
> In the Novena end of the spectrum, I think it is the case that both
> you and I have "early" Novenas. Mine is from the alpha series at
> least, and I think I remember you mentioning something similar too.
>
> If it's on the dev-bridge board, I suspect the size of the annular
> rings of the via's. I've already made a note to increase that for any
> possible future revisions. The thing with annular rings is that if
> the manufacturers drilling isn't precise enough, one can get bad
> electrical connections in between copper layers.

Anyway, masking the address down below this line, the fmc-test runs
happily, at least until the board gets nudged, and the connector gets
unseated.

Masking means we lose the upper 5 bits of address space, but we still
have 19 bits, which as much as we ever had with EIM. (Which makes me
wonder why we're planning on an even bigger address space for the alpha
board.)

3) I was disturbed to find in fmc_read_32() that we have to read each
word twice. Removing the redundant read, it returns the result of the
previous read request.

Down in the verilog, I notice the fmc_arbiter_cdc module has a 2-cycle
delay "to compensate registered mux delay in user-side logic", but I
haven't traced through enough to understand what that means. Perhaps
Pavel can comment?

In the long term, I *really* want to get rid of this double read, so we
can do memcpy() to/from the FPGA, because HAL_SRAM_Read_32b() supports
that. In the short term, I can live with it, while I get the rest of the
software up and running.

4) I've integrated Pavel's new clock manager, and confirmed that it
doesn't break the EIM design.

5) I'm currently integrating the FMC arbiter with the rest of the cores
(starting with the hash cores, working up from there). Should have that
done by the end of the day.

Pavel's novena_fmc_top doesn't connect to the noise circuit. Looking at
Fredrik's schematics, it appears to be pin F_DX18 on the connector.
Looking at the ucf file for Bunnie's novena-gpbb-fpga project, that
appears to be H7 on the FPGA. But notice there are two logical leaps
here. I'll confirm that once I've got the basic connectivity working.

				paul