[Cryptech Tech] STM32F4 <-> Novena Bridge

[Jacob]

On 6/6/2015 9:30 PM, Павел Шатов wrote:
> On 06.06.2015 17:06, Jacob wrote:
>> On 6/6/2015 4:13 PM, Fredrik Thulin wrote:
>>> On Friday, June 05, 2015 11:08:48 PM Jacob wrote:
>>>> On 6/5/2015 10:40 PM, Павел Шатов wrote:
>>>>> Hello!
>>>>>
>>>>> Fredrik, this is mostly for you. My suggestions regarding
>>>>> connection of
>>>>> STM32F4 to Novena are listed in the attached PDF file.
>>>>>
>>>>> --
>>>>> With best regards,
>>>>> Pavel Shatov
>>>>
>>>> Apologies if I've missed some important development, but what is the
>>>> purpose of creating that bridge PCB? no memory/fpga chips on board?
>>>> I guess there has been some private communication on this?
>>>
>>> You haven't missed anything - apologies for not having said anything
>>> on list
>>> that you could have missed ;).
>>>
>>> In Stockholm, we decided we wanted to do the STM32<->FPGA (FMC)
>>> interface
>>> design and implementation in parallel with waiting for the design and
>>> layout
>>> of the Alpha board.
>>>
>>> To be clear, we intend to make a small internal dev-board that will
>>> connect
>>> the FPGA on the Novena to an STM32 M4 on the dev-board, just for
>>> development
>>> of the FMC interface and maybe some early speed testing communication
>>> with
>>> already finished cores.
>>>
>>>> P.S. trying to get myself re-oriented, I see that the alpha board
>>>> strategy wiki needs urgent updating...
>>>
>>> Thanks for the reminder, I'll see to that shortly.
>>>
>>> /Fredrik
>>>
>>
>> Thanks for the explanation. Very good idea to test the I/F before
>> committing to the full alpha.
>>
>> Two comments:
>>
>> 1. I suggest to put a serial flash and a SDRAM memory chip on the test
>> board: external serial flash for flexible bootloading, and a SDRAM to
>> verify FMC logic and overall test board health while isolating the
>> Novena FPGA (the latter adds quite a bit of signal propagation unknowns,
>> especially being off board, and you want to test and verify the
>> operation incrementally).
>
> Jacob, I'm sorry, I don't completely understand your suggestion
> regarding SDRAM. We actually found out, that there's
> STM32F429I-DISCOVERY board. It is like very cheap and has on-board
> SDRAM. I think, we can use this board, if we want to verify FMC <->
> SDRAM operation. Our primary goal with this small adapter board though
> is to verify FMC <-> FPGA connection, because right now we don't have an
> endpoint for FPGA, that can talk to STM32F4 over FMC. We thought, it
> would be reasonable to develop and verify FMC arbiter by the time we
> receive assembled Alphas, to be able to test them right away.

First, I want to correct parts of my comment:
   a. When I said "serial flash" I meant "serial EEPROM"

   b. The serial EEPROM is used not for bootloading as much as to keep
      a convenient data store during testing, especially if the STM32
      architecture has no separate data flash bus apart from program
      flash bus (I am not familiar with its architecture). The SPI line
      can interface to the serial EEPROM, which make it very convenient.
      However, this suggestion is "nice to have" - nothing major if
      dropped.

My suggestion for a SDRAM chip is just to help in debugging the test 
board in case the designer doesn't see any response from the FPGA, which 
is a probable scenario due to the FPGA being off-board and in addition 
requires some programming.
Imagine that you get the test board from the assembly house, take it to 
the lab and connect it to the Novena connector and to a power supply. 
You download the code into the MCU and then - nothing happen.
You check voltages - everything is OK. Is the problem with the design, 
board, the program you uploaded into the STM32, the lines that go 
through the connector to the FPGA, the FPGA itself or is it the FPGA 
code? Or is it severe signal integrity or timing issues?

I recommend to put a "quick verifiers" on the board: a LED that you can 
programmatically flash on-off - verify that the MCU gets the required 
power and that it sees its clock and can run a program. Since the FMC is 
the main thing you want to test here, I would also put a small SDRAM on 
board to verify bus operation. If everything checks out OK, only then I 
would look at the lines going to the FPGA, the connector and the FPGA 
itself.

>
>> 2. Pavel PCB sketch shows the 2 power planes , 5V and 3.3V, separated
>> and connected only via the LDO. Since the proposal is for a 4-layer
>> board with internal layer planes (one GND and one mixed Power), the
>> memory/CTRL/CLK traces from the MCU to the Novena connector will see a
>> good reference plane (GND) from one external layer, and a split plane
>> from the other external layer. This is not good from Signal Integrity
>> and return currents POV. The PCB number of layers and plane separation
>> need to be considered after you finish the schematic so one can decide
>> what would be the best layout approach.
>
> Good point, Jacob! I completely agree, that discontinuities in reference
> plane degrade signal integrity for high-speed signals. FMC interface can
> operate at 90 MHz max. I don't know, whether this split will be that
> important at that frequency or not.
>

Signal Integrity (SI) issues are due to signal rise-time and trace 
length and topology. The clock usually correlate to rise-time but not 
always (it's the semiconductor technology and gate I/O design that 
determines the rise-time). Normally designers start to simulate SI on 
signals 30MHz and above, or rise time < 10 nS if the signals propagate 
over more than a few centimeters down the trace, especially if the 
characteristic impedance is problematic.

In addition to SI issues over a split, there is a major issue of EM 
radiation: the return current from the signal far end needs to follow 
around the split to return to the driver, thus creating a large loop of 
current ( = radiating energy). We certainly don't want that - even for a 
test board - not from security nor from regulatory POV.