[Cryptech Tech] dev-bridge board

[Basil Dolmatov]

dol@ с iPad

> 20 окт. 2015 г., в 20:47, Pavel Shatov <meisterpaul1 at yandex.ru> написал(а):
> 
>> 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.
I would not 
> 
>> 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
> <fmc_cdc_latency.png>
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech