[Cryptech Tech] dev-bridge board

[Pavel Shatov]

On 20.10.2015 18:48, Paul Selkirk wrote:
> 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.)

Noticed the same thing. High speed and mechanical reliability are not 
very good friends usually.

> 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?

Well, this particular place configures latency of user-side read logic. 
I've attached a screenshot from the simulator:

1) first tick: read enable flag gets asserted;

2) second tick: user-side logic detects this flag, core selector decodes 
address and registers input data;

3) third tick: FMC arbiter captures previously registered data from 
user-side logic.

So, there's 2-cycle delay between assertion of read enable flag and 
value on input data bus becoming valid.

This particular configuration assumes, that our top-level core selector 
has registered mux. I assume, that you're asking, because this setup is 
not very convenient for us? If you need core selector to be purely 
combinatorial (i.e. always @(fmc_addr), not always @(posedge sys_clk)), 
then this delay should be changed to 1-cycle.

> 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.

I can't tell you how I *really-really-really* wanted to get rid of that 
double read :( I spent several weeks pulling my hair out and banging my 
head against the wall trying to fix it. I just don't have any more 
nerves to spend on it. If anyone wants to try and fix this, I can 
provide full details on the problem. The short story is like, on one 
hand STM32 has a dedicated FMC_NWAIT pin, that can be used in 
variable-latency data transfer mode. On the other hand STM32 also has a 
very nasty hardware bug associated with FMC_WAIT, that causes processor 
to freeze under certain conditions. Because of this FMC_NWAIT cannot be 
used and FPGA can't properly signal to STM32, when data transfer is 
done. Because of that we have to read two times. I'm afraid, I can't fix 
this, I'm sorry.

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

And I already have a better one, which has active-low reset, according 
to recommendations from Joachim and Bernd. I just need to figure out how 
to upload it.

> 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.

I've just checked schematics, you're right, this pin is H7.


--
With best regards,
Pavel Shatov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fmc_cdc_latency.png
Type: image/png
Size: 169664 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20151020/1e040c17/attachment-0001.png>