[Cryptech Tech] Short note on the current FPGA activities

[Basil Dolmatov]

dol@ с iPad

> 25 янв. 2015 г., в 3:02, Шатов Павел <meisterpaul1 at yandex.ru> написал(а):
> 
> Hello, Joachim!
>  
> I have a suggestion on how to organize the clock network inside of an FPGA in our project. I've attached a picture for it to be more clear, please take a look. My suggestion is to separate the EIM interface from other parts of our design using either a pair of FIFOs or a dual-port RAM. I don't understand bunnie's original design with 8(!) BUFGs and TIG constraints. Do you understand his timing closure? Floorplanning at 133 MHz seems to be an overkill and why are there no IODELAY2 primitives? I suggest that we rework his design, because having two independent clock domains will allow EIM arbiter to run at BCLK frequency and the rest of the logic to run at any other arbitrary frequency (not necessarily BCLK or BCLK/2). EIM arbiter should include very simple logic to handle EIM access from the CPU, its job is to either enquere/dequeue data to/from the FIFOs or read/write to/from RAM as necessary. The other part of our design should include a DCM or PLL-based clock manager, that will generate some frequency to clock cores, I've called it SYS_CLK for now. We can use CLK2 (50 MHz) reference clock, that is provided by the CPU to generate any SYS_CLK frequency that we need (80 MHz for example), we can also generate other clocks that we need using the same DCM. If we need say 40 MHz clock (CLK_Y in the picture), it will be tightly phase-aligned with SYS_CLK, because both clocks will be generated by the same source. I believe that having two independent clock domains is better because we can at first debug EIM arbiter and be sure that we have reliable data transfer between the CPU and the FPGA. We can also change SYS_CLK as we want, if we run into tight internal timing, we can just decrease SYS_CLK and this will not affect EIM arbiter timing.
>  
> In your `novena_eim_base' you have a readme file with a plan in the end. I have similar plan in my mind, I've started working from left to right, if you look at my picture. The leftmost block (not drawn) is the CPU itself. The very first thing that we need to do is to configure EIM on iMX6Q. Here comes... setup_fpga() that you call rubber chicken voodoo. I find bunnie's original code with all these memcpy(0xDEADBEEF, 0xHEXVALUE) very difficult to debug. Have you figured out what mode is used in his code? Sync or async? I've created C header with all the EIM-related registers and corresponding bitmaps. How can I upload it to the repository btw? Do I need some special write permission or something?
>  
> To sum up I suggest the following smaller sub-plan of your plan for now:
>  
> 1) Sort out how to properly configure EIM on iMX6Q.
> 2) Discuss clocking structure.
> 3) Write EIM arbiter.
> 4) Add small amount of BRAM instead of cores in the right side of the picture.
> 5) Write test program to fill BRAM with some data pattern, read it back and compare.
6) Agree on, define, document and set up internal FPGA bus for connecting cores and interfaces.
>  
> After we complete 5)
6)...

> and have stable interface between the CPU and the FPGA we can move to the right and start adding cores to our design.
All cores should have standard bus interface and we need addressing table for this bus for all cores we create and use. 
Something like /etc/services ;) 
>  
> Regarding 1) I've rewritten bunnie's setup_fpga() using my header file with convenient bitfields, this way it's much easier to debug it. Number 2) is in the attached picture, do you have any suggestions to improve it? Speaking of 3) I've written write access handler and started writing read access handler.
>  
> Waiting to hear from you,
> Paul Shatov
>  
>  
> 24.01.2015, 11:19, "Joachim Strömbergson" <joachim at secworks.se>:
>> 
>> 
>> Aloha!
>> 
>> As you probably have seen there has been a series of commits (and more
>> will happen the next days.) I just wanted to explain what I'm doing.
>> 
>> In the process of getting our cores to work with the EIM interface and
>> the clocks in the Novena I have ended up with a lot of test stuff. Also,
>> the general top level of the Novena is somewhat unstructured and fairly
>> large making it hard to separate what is needed, what needs to be changed.
>> 
>> I therefore decided to do some refactoring and cleanup. The goal is to
>> have a top level that contains the clock and reset implementation in a
>> submodule and the complete EIM interface with its associated clock
>> implementation in second submodule. This leaves the top short and easy
>> for Novena FPGA implementors to see where to add their own logic.
>> 
>> During the cleanup I'm also fixing warnings and esp looking at the clock
>> implementation. I've added the generation of a 66 MHz EIM clock in phase
>> with the 133 MHz clock.
>> 
>> I'm not done the refactoring yet so big parts of the EIM is still left
>> to add. Hopefylly I will be back at full standard EIM functionality on
>> Monday. For those that want to look at the code it is here:
>> 
>> http://wiki.cryptech.is/browser/user/js/test/novena_eim_base
>> 
>> It really is a playground - lots of dragons there and not to be used for
>> anything remotely important.
>> 
>> And yes Rob, another repo. Sorry. We will need to clean up as soon as I
>> have the EIM issue done.
>> 
>> - -- 
>> Med vänlig hälsning, Yours
>> 
>> Joachim Strömbergson - Alltid i harmonisk svängning.
>> ========================================================================
>>  Joachim Strömbergson          Secworks AB          joachim at secworks.se
>> ========================================================================
>> 
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>> 
>> iQIcBAEBCAAGBQJUw1VzAAoJEF3cfFQkIuyNLXYP/j8itqpKasNpflK9fzFqnQEf
>> 1fp9Hlu1NIt6W8fwIu8BGJTLQ1W2usjk2SNCCOJGpuFGPiBW7wF+3XQsL6Fb+K/Y
>> +8HeYqQT4gm3S8Tj/Dp8A11bKFBUULGI8Q7T/taFYz518e0JLgulwR8NkRCVqMnt
>> uHMHOY5VQRTYPmjW4uf6zGvblI2ghW3kzM6stODhysU15v1x18KyrtfmJKUxz3jK
>> duTjkTif59Nl0p7d5Tjx+Vd63SE2aFJqnYZ5H//exDR7MKG6Q8OJYH/J0M1eEpDQ
>> b4F0FxUorgzeh61Oyykadw0/gaMsNZZ7cHhg+NOEky/L0ROSpUzfvC+OneY+9pad
>> W75FkeW/7MdyXmgOuImTfsY7aA1Q39A5E/LrVxVOzq+RTkJC/TYSEFGLwUz3N/yf
>> ZOWkHk8CG+VZT4GCY5okQtEi2IajbF099VYO/FEXOqtTHqwdPgfCCCdcg4b4FKlA
>> 0VcX+WVJadHBkbygGlEMIuIOqA3CPPIy9bNlvNDA49aKIx6sdJ/xUqC9JmAT8bTY
>> H0RultquJrhYyRQYIXeiUq1R0NGa/ipKJV1aZIE5uXvT/OVZ18j46d1KRfrGA0Ti
>> u1AJWqIC+bYXc/+YbwDGGrhrIOOBEVjP4OYj8mNVssg+JdOzNKOSdiN6pUOB6RDI
>> TXqCBJ/Vhe6G4KfHKSSg
>> =3FsL
>> -----END PGP SIGNATURE-----
>> 
>> _______________________________________________
>> Tech mailing list
>> Tech at cryptech.is
>> https://lists.cryptech.is/listinfo/tech
>> 
> <NovenaClocks.pdf>
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cryptech.is/archives/tech/attachments/20150125/bfaa6876/attachment-0001.html>