{"id":19065416,"url":"https://github.com/newaetech/cw305-arm-designstart","last_synced_at":"2025-04-28T11:28:00.645Z","repository":{"id":40246600,"uuid":"270734420","full_name":"newaetech/CW305-Arm-DesignStart","owner":"newaetech","description":"Instruction and files for porting Arm DesignStart to CW305.","archived":false,"fork":false,"pushed_at":"2023-12-06T18:57:02.000Z","size":1784,"stargazers_count":9,"open_issues_count":0,"forks_count":2,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-04-20T22:59:42.588Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/newaetech.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2020-06-08T16:08:06.000Z","updated_at":"2025-02-20T18:29:56.000Z","dependencies_parsed_at":"2022-07-09T15:37:43.877Z","dependency_job_id":null,"html_url":"https://github.com/newaetech/CW305-Arm-DesignStart","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/newaetech%2FCW305-Arm-DesignStart","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/newaetech%2FCW305-Arm-DesignStart/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/newaetech%2FCW305-Arm-DesignStart/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/newaetech%2FCW305-Arm-DesignStart/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/newaetech","download_url":"https://codeload.github.com/newaetech/CW305-Arm-DesignStart/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":251304011,"owners_count":21567789,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-09T00:49:51.000Z","updated_at":"2025-04-28T11:28:00.623Z","avatar_url":"https://github.com/newaetech.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Introduction\n\nArm freely provides its Cortex M1 and Cortex M3 processors as soft-core IP for\nevaluation through its\n[DesignStart](https://www.arm.com/resources/free-arm-cortex-m-on-fpga)\nprogram. This will require one to both *Apply* and sign-up. Arm also\nprovides a workflow and tutorials for implementing the\nM1 or M3 on the popular [Digilent Arty\nA7](https://reference.digilentinc.com/reference/programmable-logic/arty-a7/start)\nFPGA platform.\n\nIn this note we explain how to port the Arty DesignStart platform to our own\n[CW305](https://rtfm.newae.com/Targets/CW305%20Artix%20FPGA/) or CW312 A35\nplatform.  We show how to generate the FPGA bitfile, then we show how to build\nour\n[standard simpleserial AES victim\nfirmware](https://github.com/newaetech/chipwhisperer/tree/develop/hardware/victims/firmware/simpleserial-aes) and run our standard Jupyter tutorials.\n\nThe end result is a powerful side-channel platform with a customizable Arm\nCortex target, which you can use as a starting point and customize for your\nown needs. Here are a few examples of what you can do:\n\n- add additional peripherals and interfaces to the Arm processor\n- instantiate multiple Arm processors\n- add additional side-channel attack logic to the target FPGA -- for example,\n  [Arm trace sniffing logic](https://github.com/newaetech/DesignStartTrace).\n\nBefore starting, it's a good idea to watch the series of videos that Arm put\ntogether to show the development cycle for DesignStart on the Arty board:\nhttps://youtu.be/kSaQJGSu-yI\n\nThis will give you an idea of what's possible and what the development cycle\nis like.\n\n\n## Warning!\nPorting the Arm IP from the Arty platform to one of our target FPGAs requires you\nto do a lot of work in Vivado. This write-up assumes some prior experience\nwith Vivado.  It is not a Vivado tutorial! Vivado can be a fickle tool and\nits error messages will have you scratching your head if you aren't familiar\nwith FPGA development. Attempting to follow the steps below without any FPGA\ndevelopment experience is almost guaranteed to be a frustrating experience.\nThe instructions below are very long and fairly detailed, but they are not\nintended for beginners.\n\nOn the other hand, if you've used Vivado before, then don't let this scare\nyou away. You probably won't be doing anything you haven't done before!\nFor an experienced FPGA developer, there's nothing hard or tricky here. The\nintent of this note is to show that it *is* possible to run DesignStart on\nour target FPGAs, and hopefully save you some time in getting there.\n\n\n## Limitations\n- The Cortex processors included in the DesignStart release have limited\n  configuration options.\n- The free version of Keil does not support programs larger that 32 Kbytes (the\n  free version includes a 30-day trial for the unlimited professional version).\n\n# Requirements\n## Hardware Requirements:\n- CW-Nano, Lite, Pro or Husky\n- CW305 or CW312-A35\n\n## Software Requirements:\nThese are all free downloads:\n- Xilinx Vivado version 2019.1\n    * other versions may work but some tweaks to the steps may be required\n    * Xilinx makes it easy to install arbitrary versions, so please use\n      2019.1!\n- Keil uVision version 5.26.2.0\n    * current version is 5.30, should work as well\n- Arm DesignStart for Xilinx FPGA package\n\nWhile Vivado is available for Windows and Linux, Keil is Windows-only.\nThe recipe provided here was tested with Windows 10.\n\n### Install Xilinx Vivado\n\nCreate a Xilinx account and download Vivado Design Suite 2019.1 from \nhttps://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/vivado-design-tools/archive.html.\nYou should select the original 2019.1 release, *not* the update 1 or update 2\nversion.  You want the one where the Windows installer has this MD5 checksum:\n\n`743003070fb77857ad098bd6873bdf0b`\n\nWhen you run the installer, choose the the Vivado HL WebPACK install.\n\nOther versions of Vivado may work as well, but the Vivado project files\nprovided by Arm were created with this version of Vivado; there may be\nhiccups if you use a different version (in particular, the Xilinx SDK\nappears to have undergone significant changes in 2019.2).\n\n### Download DesignStart package\n\nCreate an Arm account and download the DesignStart package \nfrom https://www.arm.com/resources/free-arm-cortex-m-on-fpga.\n\nYou have the option of choosing the M1 package or the M3 package. These\ninstructions are written for the M3 target, but they will work for the M1\ntarget as well -- just substitute M3 for M1 wherever you encounter it in the\nsteps below.\n\nThe M3 fits on the XC7A100 FPGA with lots of room to spare for other logic\n(approximately 20% utilization); it may be tight on the XC7A35 FPGA. The M1\nshould fit very comfortably on both.\n\nThese instructions were developed and tested with version r0p1-00-rel0.\n\n### Install Keil\nDownload and install the Keil IDE from\nhttps://www.keil.com/demo/eval/arm.htm.\n\n\n\n# Creating the FPGA bitfile\nThis is by far the longest step, so buckle in. \n\nWe're going to remove some unnecessary peripherals around the reference\nCortex design and change the configuration of others. The goal is to make a\ntarget which resembles our STM32 targets, which communicate with\nChipWhisperer via UART. This will allow our existing Jupyter notebook\ntutorials to be very easily ported to this platform.\n\n(Other approaches are possible too! That's the beauty of having the target as\nsoft IP in an FPGA. For example one may choose to leverage the 8-bit\nparallel data interface provided by \n[CW305.py](https://github.com/newaetech/chipwhisperer/blob/develop/software/chipwhisperer/capture/targets/CW305.py),\nor make up an entirely new interface.)\n\nSince this guide was originally developed for the CW305 target, it contains\nmany references to the CW305; unless otherwise noted, these also apply to the\nCW312 A35 target.\n\n1. Open the Arm DesignStart user guide\n(`\u003cArm bundle\u003e/docs/arm_cortex_m3_designstart_fpga_xilinx...pdf`)\nand follow the instructions in sections 2.1, 2.2, and 2.3.\n\n\n2. Clone the DesignStart project in Vivado:\n   - Open Vivado and open either the DesignStart project, found here:\n     `v:/hardware/m3_for_arty_a7/m3_for_arty_a7/m3_for_arty_a7.xpr`\n   - There will be some warnings; this is ok.\n   - File \u003e Project \u003e Save As, with a new project name of\n     CW305\\_DesignStart, to `V:/hardware/CW305_DesignStart` as shown below:  \n   ![picture](images/new_project.png)\n\n2. Copy `v:/software/m3_for_arty_a7/` to `v:/software/CW305_DesignStart`\n\n3. Follow the instructions in section 2.4 of the Arm DesignStart user guide,\n   but replace `m3_for_arty_a7` with `CW305_DesignStart`.\n\n4. Make sure `Arty A7-100` is selected at `Tools -\u003e Settings -\u003e Project Settings\n   -\u003e General -\u003e Project device` afterwards.\n\n5. Do not follows steps 2.5 and 2.6:\n    - Step 2.5 is not necessary because our CW305 port does not use QSPI\n      memory.\n    - Step 2.6 is not necessary because we will not be simulating our CW305\n      port in Vivado. (You, on the other hand, may wish to do so --\n      especially if you decide to deviate from this recipe.)\n\n6. Restart Vivado. Then in Vivado, update the block diagram. There is a *very long* list of\n   changes to make! At the end of the changes, we'll show a picture of what\n   the updated block diagram should look like, so that you can double-check\n   that you've made all the changes correctly.\n    - Double click on the block diagram file `m3_for_arty_a7_i` in the\n      Design Sources tree; there will be errors but that's ok.  \n    ![picture](images/open_bd.png)\n    - in the block diagram window, delete the following blocks:\n        - `axi_gpio_0`\n        - `axi_gpio_1`\n        - `axi_quad_spi_0`\n        - `daplink_if_0`\n    - delete the following ports which are now dangling:\n        - `rgb_led`\n        - `led_4bits`\n        - `dip_switches_4bits`\n        - `push_button_4bits`\n        - `qspi_flash`\n        - `DAPLink`\n    - connect the dangling `usb_uart` port to the `axi_uartlite_0` block\n\n    - Add AXI GPIO block:\n        - rick-click on diagram \u003e Add IP, search \"gpio\", select AXI GPIO\n        - double-click the newly created `axi_gpio_0` block to configure it:\n            - select \"All Outputs\"\n            - set width to 1\n            - click OK\n        - connect left-side ports of `axi_gpio_0` block:\n            - `S_AXI` to `M01_AXI` port on the `axi_interconnect_0` block\n            - `s_axi_aclk` to the same wire that goes to the `s_axi_aclk` port\n              of other blocks\n            - same for `s_axi_aresetn`\n        - right-click on GPIO port of `axi_gpio_0` block and select \"Create\n          Interface Port\"; name it `gpio_rtl_0`\n\n    - Update `axi_interconnect_0` block:\n        - move the `M03_AXI` connection on the interconnect to `M02_AXI` so\n          that only the first three `Mxx_AXI` ports are used\n        - double-click on the `axi_interconnect_0` block to edit its\n          properties; change number of master interfaces from 6 to 3\n\n    - Double-click on the `axi_uartlite_0` block to edit its configuration:\n        - change AXI clock frequency from AUTO to MANUAL and set it to 20\n          MHz\n        - set the baud rate you intend to use; we'll use 38400\n        - click OK  \n        ![picture](images/axi_uartlite.png)\n\n    - Double-click the `Clocks_and_Resets` block:\n        - delete the `clk_wiz_0`, `proc_sys_reset_DAPLink`, `i_interconnect_aresetn`,\n          `i_peripheral_aresetn1`, and `i_sysresetn_or` blocks\n        - delete the dangling `clk_qspi` and `aux_reset_in` ports\n        - connect the `mb_reset` output of `proc_sys_reset_base` to the\n          input of `i_inv_dbgresetn` and to the input of `i_in_sysresetn1`\n        - connect the `interconnect_aresetn` output of `proc_sys_reset_base`\n          to the `interconnect_aresetn` output port\n        - connect the `peripheral_aresetn` output of `proc_sys_reset_base`\n          to the `peripheral_aresetn` output port\n        - connect the `sysresetreq` input pin to the `mb_debug_sys_rst`\n          input of `proc_sys_reset_base`\n        - connect the `xlconstant_1` output to the `aux_reset_in` input of\n          `proc_sys_reset_base`\n\t\t- right-click in the design window, select \"Add Module\" and select\n\t\t  `clk_select.v`.\n\t\t- Add a connection from `clk_select_0-\u003esys_clock` to the `sys_clock`\n\t\t  input pin.\n        - right-click in the design window, select Create Pin, and create an\n          input pin named \"locked_i\"; connect it to the `dcm_locked` input of\n          `proc_sys_reset_base`\n        - connect the `sys_clock` input to the `clk_cpu` output and to the \n          `proc_sys_reset_base` `slowest_sync_clk` input\n        - the `Clocks_and_Resets` block diagram should now look like this:\n        ![picture](images/clocks_and_resets.png)\n\n    - Returning to the main block diagram, right-click in the design window,\n      Create Port, and fill in these properties:\n        - name: `ext_clock`\n        - direction: output\n        - type: clock\n        - click OK\n        - wire the newly-created `ext_clock` to the `clk_cpu` net\n        ![picture](images/ext_clk.png)\n\n    - Repeat the above to create an input data pin named `locked`,\n      connected to the `locked_i` input of `Clocks_and_Resets`\n\n    - Repeat the above to create an output data pin named `M3_RESET_OUT`,\n      connected to the `sysresetn` output of `Clocks_and_Resets`\n\n    - Delete the `tri_io_buf_0` block\n        - delete the dangling `TDO[0:0]` output port\n        - for each of the following `Cortex_M3_0` outputs, right-click on\n          the output pin, select Create Port, and accept the defaults:\n            - `TDO`\n            - `nTDOEN`\n            - `SWV`\n\n    - Add many more missing ports:\n        - right-click on the `SWDITMS` input of the `Cortex_M3_0` block and\n          select \"Create Port\"\n            - change name to `SWDI`, set type to data\n\n        - do the same with `SWCLKTCK` input of the `Cortex_M3_0` block\n            - name: `SWCLK`\n            - direction: input\n            - type: clock\n            - frequency (MHz): 20\n\n        - select `CM3_CODE_AXI3` port of `Cortex_M3_0` block, then\n          right-click in the design window and select \"Create Interface\n          Port\"; keep the pre-filled values and click OK  \n        ![picture](images/CM3_CODE_AXI3.png)\n        - right-click on `CM3_CODE_AXI3` output port, select \"External\n          Interface Properties\", and set the Clock Port to `ext_clk`\n        - for each of the `JTAGNSW`, `JTAGTOP`, `SWDO`, `SWDOEN` ports of\n          the `Cortex_M3_0` block:\n            - select the port, then right-click in the design window, select\n              \"Create Port\", and accept  the default pre-filled values\n\n    - Delete the `xlconcat_1` block\n        - right-click the CFGITCMEN[1:0] input of the `Cortex_M3_0` block\n          and select \"Create Port\"; accept pre-filled settings and click\n          \"OK\"\n\n    - Almost done! This is the last big step:\n        - double-click the `xlconstant_1` block and change the \"Const Val\"\n          field from 1 to 0; click OK\n        - right-click the `xlconstant_1` block, select copy\n        - right-click in the design window and select paste; repeat this 6\n          times\n            - this will create the blocks `xlconstant_2` through to\n              `xlconstant_7`\n        - connect the `dout` port of each of our seven `xlconstant_*` blocks\n          to an unconnected `In*` port of the `xlconcat_0` block\n        - you should have something that looks like this:  \n          ![picture](images/xlconstant.png)\n\n    - Assign missing addresses: switch to the Address Editor tab\n        - assign an address to `axi_gpio_0` by right-clicking in its Offset\n          Address column and select \"Assign Address\"\n        - do the same to `CM3_CODE_AXI3`  \n          ![picture](images/addresses.png)\n\n    - Configure Arm processor (optional): there are a limited number of\n      configuration options. The default values are fine, but you may wish\n      to enable additional debug facilities.\n\n    - The block diagram changes are now done; verify that it looks like this:  \n    ![picture](images/final_bd.png)\n\n    - Phew! Now save and validate:\n        - File -\u003e Save Block Design\n        - Tools -\u003e Validate Design\n        - If you get a \"Validation successful\" message: congratulation!\n          You've completed the most tedious part of the porting exercise!\n          Otherwise, any errors **must be** investigated and resolved.\n        ![picture](images/success.png)\n\n7. Change the target from Arty to CW305:\n    - Settings \u003e Device \u003e Parts: choose the correct part for your target\n        - for the CW305 this is either `xc7a100tftg256-2` or `xc7a35tftg256-2`\n        - for the CW312 A35 target this is `xc7a35tcsg324-1`\n    - upgrade IP blocks as required: next to the message \"The design has 23\n      blocks that should be upgraded.\", click on \"Report IP Status\", then\n      \"upgrade selected\"\n    - you will see three critical warnings related to the `proc_sys_reset_base`\n      blocks\n      - open the `proc_sys_reset_base` block (inside the\n          `Clocks_and_Resets` block) and fix its configuration:\n            - set Ext Reset Active Width to 1\n            - set Aux Reset Active Width to 1\n    - save and validate again (there should be no errors or critical\n      warnings) \n    - click on \"Generate Block Design\" (should be clean)\n\n8. Replace the top-level design file:\n    - File \u003e Add Sources \u003e Add or create design sources \u003e Next;\n        - Add Files, select all `*.v` files in \n          [`src/hardware/`](src/hardware/)\n        - select \"Copy sources into project\"; Finish\n    - in the Sources tree, right-click on `CW305_designstart_top.v` and select\n      \"Set As Top\"\n    - right-click on the old top-level file, `m3_for_arty_a7_wrapper`, and\n      select Remove File from Project\n    - also remove `tri_io_buf` from the project\n\n9. Replace the constraint file:\n    - File \u003e Add Sources \u003e Add or create constraints \u003e Next;\n        - Add Files, select either\n          [`CW305_designstart.xdc`](src/hardware/CW305_designstart.xdc)\n          or\n          [`a35_designstart.xdc`](src/hardware/a35_designstart.xdc)\n        - ensure \"Copy constraints files into project\" is selected; Finish\n    - in the Sources tree, expand Constraints and constrs\\_1, right-click\n      the file you just added, select \"Set as Target Constraint File\"\n    - remove the other two constraint files (`m3_for_arty_a7.xdc`,\n      `m3_for_arty_a7_impl.xdc`) from the project\n\n10. Generate the FPGA PLL: this is needed because we've deleted the PLL from\n    the `clocks_and_resets` block and moved it to the top-level Verilog.\n    Under \"Project Manager\", click on \"IP Catalog\", search for \"clock\n\twizard\", and double-click on the \"Clocking Wizard\" search result (Customize\n\tIP). In the \"Clocking Options\" tab, select the following options:\n     - MMCM\n     - Frequency Synthesis\n     - Phase Alignment\n     - Safe Clock Startup\n     - Balanced\n     - set clk_in1 frequency to 100 MHz\n\n    In the \"Output Clocks\" tab, set the following:\n     - clk_out1 requested frequency to 100 MHz\n     - clocking feedback: Automatic Control On-Chip\n     - Enable Optional Inputs/Outputs: enable locked, disable reset\n\n    Then click \"OK\", and \"generate\" (this can take a while).\n\n11. If using the CW312 A35 target, go to `Tools -\u003e Settings -\u003e Project Settings\n   -\u003e General -\u003e Verilog options`, click on the three dots (`...`), and add a\n   define with a name of `SS2_WRAPPER` (no value needed).\n\n12. Generate the FPGA bitstream: in the Flow Navigator pane, select \"Generate\n    Bitstream\". This will take on the order of 30 minutes. There should be\n    no errors, but there will be warnings. In particular, timing will not be\n    met: I haven't figured out how to change the target clock rate from 100\n    MHz to something more reasonable. We'll be setting the actual clock to\n    something much lower, so that's ok.\n\n    *It's possible that a \"route\\_design ERROR\" will occur. The runme.log\n    file in the implementation directory would show no errors, and\n    hs\\_err\\_pidXXXXX.log would show: \"An unexpected error has occurred\n    (EXCEPTION\\_ACCESS\\_VIOLATION)\". In this case, try to generate the\n    bistream again (and again?) until it completes successfully. Thanks\n    Vivado :-)*\n\n\n13. File \u003e Export \u003e Export Hardware, to `V:/software`\n\n\n# Generate the BSP (Board Support Package)\n\n1. In Vivado, select File \u003e Launch SDK:\n    - set exported location to `V:/software/`\n    - set workspace to `V:/software/CW305_DesignStart/sdk_workspace/`\n\n2. In the Xilinx SDK tool, select File \u003e New \u003e Board Support Package. Ensure\n   that `CW305_designstart_top_hw_platform_0` is selected in the Hardware\n   Platform dropdown; click Finish.\n    - In the BSP Setting pop-up, change the OS version to 6.7.\n    - Under \"Overview\", click on standalone.\n    - Even though stdin and stdout are both correctly set to\n      `axi_uartlite_0`, they must each be changed to none and then back to\n      `axi_uartlite_0`; failure to do this will possible result in a\n      non-functional UART peripheral. Then, click OK.\n\n3. To ensure that the UART is properly configured, in Project Explorer\n  on the left-hand side, navigate to `standalone_bsp_0/Cortex_M3_0/include`,\n  open xparameters.h, and verify that `STDIN_BASEADDRESS` and\n  `STDOUT_BASEADDRESS` are defined:\n  ![picture](images/stdio.png)\n\n4. Copy `xpseudo_asm_rcvt.c` and `xpseudo_asm_rcvt.h` from:\n  `V:\\vivado\\Arm_sw_repository\\CortexM\\bsp\\standalone_v6_7\\src\\arm\\cortexm3\\armcc\\`\n  to:\n  `V:\\software\\CW305_DesignStart\\sdk_workspace\\standalone_bsp_0\\Cortex_M3_0\\include\\`\n\n5. Add `C:\\Keil_v5\\ARM\\ARMCC\\bin\\` to your system path envar and add\n   `C:\\Xilinx\\Vivado\\2019.1\\bin\\` to your user path envar.\n\n6. You can now exit the Xilinx SDK as we will not be using it any further.\n\n\n# Prepare to compile software\n1. Edit `v:\\software\\CW305_DesignStart\\Build_Keil\\make_hex_a7.bat`:\n    - change second last line from:\n      `copy bram_a7.* ..\\..\\..\\hardware\\m3_for_arty_a7\\m3_for_arty_a7`\n      to:\n      `copy bram_a7.* ..\\..\\..\\hardware\\CW305_DesignStart\\`\n    - delete this last line:\n      `copy qspi_a7.hex ..\\..\\..\\hardware\\m3_for_arty_a7\\testbench`\n    - change all instances of `m3_for_arty_a7.axf` to\n      `CW305_DesignStart.axf`\n\n2. Copy the following files from\n  `V:\\hardware\\m3_for_arty_a7\\m3_for_arty_a7\\` to `V:\\hardware\\CW305_DesignStart\\`:  \n    - `make_prog_files.bat`\n    - `make_prog_files.tcl`\n    - `make_mmi_file.tcl`\n\n3. Edit `v:/hardware/CW305_DesignStart/make_prog_files.tcl`:\n    - change `source_bit_file` to\n      `./CW305_DesignStart.runs/impl_1/CW305_designstart_top.bit`\n    - rename `output_bit_file` to `CW305_DesignStart.bit`\n    - rename `output_mcs_file` to `CW305_DesignStart.mcs`\n\n4. Copy the following from [src/software](src/software) to\n   `v:/software/CW305_DesignStart/`:\n   - `cw_main.c` to `v:/software/CW305_DesignStart/main/`\n   - `cw_gpio.c` and `cw_gpio.h` to `v:/software/CW305_DesignStart/gpio/`\n   - simpleserial directory to `v:/software/CW305_DesignStart/`\n   - crypto directory to `v:/software/CW305_DesignStart/`\n\n5. Copy project file\n   [`CW305_DesignStart.uvprojx`](src/keil/CW305_DesignStart.uvprojx) to\n   `v:/software/CW305_DesignStart/Build_Keil/`\n\n\n# Update MMI file\nThe Cortex target's program memory is local to the FPGA, and the program\nmemory contents is included in the FPGA bitfile. When we generated the\nbitfile a few steps ago, this was done using the reference program provided\nby Arm for their DesignStart reference design. Obviously, that won't work\nfor us.\n\nFortunately, it's possible to update the program memory content in an\nexisting FPGA bitfile without having to regenerate the bitfile from scratch.\nXilinx uses an MMI file to describe the location of internal FPGA memories,\nso that their contents may be updated. First we must generate this MMI file:\n\n1. Edit the `set part` line in\n   `V:/hardware/CW305_DesignStart/make_mmi_file.tcl`\n   to set the correct part for your CW305 board (`xc7a100tftg256-2` or\n   `xc7a35tftg256-2`).\n\n2. In Vivado, reopen the project and in the sidebar click \"Open Implemented Design\",\n   then in the Tcl console, navigate to project directory and run: `source make_mmi_file.tcl`\n\n\n# Compile software\n1. Open the project file (`CW305_DesignStart.uvprojx`) in Keil and select\n   Project \u003e Rebuild all target files\n\n2. Build should be clean except for several warnings from Xilinx SDK file\n   `xil_assert.h` having \"*last line of file ends without a newline*\";\n   consider fixing this to have a clean build.\n\n3. Note that `make_hex_a7.bat` is automatically run post-build, and any\n   errors in that script will *not* be captured in the final tally of errors\n   and warnings, so look at the build output carefully to make sure that it\n   did in fact run cleanly.\n\n\n# Update FPGA bitfile\nIn `v:/hardware/CW305_DesignStart`, run the `make_prog_files.bat` script to\nstitch the Cortex program data into the FPGA bitfile that we generated\npreviously. This should take less than a minute -- orders of magnitude\nfaster than re-generating a bitfile from scratch!\n\n**Caution!** This can silently fail if the MMI file has not been updated.\nThere will be no indication of any errors, other than an unresponsive target\nprocessor.\n\n\n# Done!\nNow you can have fun! One thing you can do is try some of the ChipWhisperer\ntutorials. Since we have built a target which looks and feels like an STM32\ntarget (as far as the ChipWhisperer capture hardware is concerned), any of\nthe tutorials which support the CWLITEARM platform should work (if not, read\non to [debugging](#debugging) below).\n\nSimply skip over the initial part of the tutorials which deals with\nprogramming the target. This means you do **not** use `STM32FProgrammer`. \nDo not run the `%run\n\"Helper_Scripts/Setup_Generic.ipynb\"` cell; on the CW305, use the\n`Setup_DesignStart.ipynb` notebook supplied\n[here](src/jupyter/Setup_DesignStart.ipynb).\n\nOn the CW312-A35, set up as follows:\n```Python\nscope.default_setup()\ntarget = cw.target(scope, cw.targets.SimpleSerial)\nscope.clock.clkgen_freq = 20e6\n```\n\nThe following tutorials have been verified to succeed:\n- [`Lab 3_3 - DPA on Firmware Implementation of AES`](https://github.com/newaetech/chipwhisperer-jupyter/blob/master/courses/sca101/Lab%203_3%20-%20DPA%20on%20Firmware%20Implementation%20of%20AES%20(MAIN).ipynb)\n- [`Lab 4_2 - CPA on Firmware Implememtation of AES`](https://github.com/newaetech/chipwhisperer-jupyter/blob/master/courses/sca101/Lab%204_2%20-%20CPA%20on%20Firmware%20Implementation%20of%20AES%20(MAIN).ipynb) (requires a slightly higher number of traces, around 150)\n\nNote that communication with the softcore is done over the UART interface,\nusing the IO1 and IO2 lines of the 20-pin ChipWhisperer connector (i.e. just\nlike with our \"normal\" microprocessor targets), **not** the CW305 USB\ninterface. This means that the CW305 cannot be used in standalone mode; it\nneeds to be connected to a [ChipWhisperer capture\ndevice](https://rtfm.newae.com/Capture/).\n\nDo not try to run the \"normal\" CW305 FPGA target notebooks (like\n[this one](https://github.com/newaetech/chipwhisperer-jupyter/blob/master/demos/PA_HW_CW305_1-Attacking_AES_on_an_FPGA.ipynb));\nthese notebooks communicate with the target using the USB interface. That USB\ninterface is not connected to the DesignStart softcore, and so these notebooks\nwill not work with this DesignStart core.\n\n## CW305 switches\n\nThe SW4 push-button is connected to the M3 reset; it can be used to reset\nthe running program.\n\nThe J16 DIP-switch selects the M3 input clock:\n- 0: the input clock is the CW305 PLL1\n- 1: the input clock is the HS2 pin (e.g. clkgen from ChipWhisperer)\nThe `Setup_DesignStart.ipynb` notebook expects J16 to be set to 0.\n\nRefer to the [CW305 documentation](https://www.newae.com/products/NAE-CW305)\nfor more information on the features and capabilities of the CW305 board.\n\nThe CW312 A35 lacks these bells and whistles.\n\n## Clock glitching (CW305 only)\n\nThe DesignStart reference design included a PLL to clean up the input clock;\nwe removed this when we modified the `Clocks_and_Resets` block in Vivado,\nbecause it's been moved to the top-level `CW305_designstart_top.v` Verilog\nfile. This was done to allow you to selectively bypass this PLL, which can\nbe useful for clock glitching. When the PLL is bypassed, the input clock\ngoes directly to the Arm core.\n\nTo bypass the PLL, call `bypass_fpga_pll()`. To use the PLL (which is the\ndefault behaviour out of reset), call `use_fpga_pll()`.  These functions are\ndefined in\n[`src/jupyter/Setup_DesignStart.ipynb`](src/jupyter/Setup_DesignStart.ipynb).\n\nOn the CW312-A35, you'll have to customize and rebuild to get this\nfunctionality.\n\n# FPGA and target resets (CW305 only)\n\nThe pushbutton labeled \"FPGA R1 USR SW4\" (near the 3 side SMA connectors)\nresets the CW305 FPGA (including the Arm DesignStart core).\n\nThe FPGA can also be reset by calling `reset_fpga()` (defined in\n[`src/jupyter/Setup_DesignStart.ipynb`](src/jupyter/Setup_DesignStart.ipynb)).\n\nFinally, to reset only the Arm core, use `reset_arm_target()`.\n\nCurrently the only FPGA logic which is unaffected by the Arm core reset is\nthe PLL bypass setting, but if you extend this work and add more FPGA logic,\nyou may find it useful to have the two separate resets.\n\nResetting the Arm core is sometimes required after startup. If the target is\nunresponsive (e.g. captures time out with no trigger), try resetting the\ntarget.\n\n# Next steps\n\n## Software modifications\nModifying the target software is easy. Make your changes and rebuild in Keil,\nthen update the previous FPGA bitfile with the `make_prog_files.bat` script.\nNo need to recompile the FPGA bitfile from scratch.\n\n## Additional information for clock glitching\n\nFor clock glitching you probably do not want to use the clock wizard. Thus, the\nPLL should be bypassed. One thing to consider is that the softcore processor now\ndirectly utilizes the `sys_clock` instead of stabilizing the clock in the FPGA\nDCM. This clock is running at a 20MHz by default.\n\nFurthermore, the glitched clock signal from the capture device is coming in on\n`hs2`. We can enable and disable glitching then with\n\n```python\n# Enable glitching\nscope.io.hs2 = \"glitch\"\n\n# Disable glitching\nscope.io.hs2 = \"clkgen\"\n```\n\nHere are some other notes when wanting to clock glitch the softcore.\n\n#### Problem: corruption of instruction data\n\nCompared to the *ASIC*, it is relatively easy to corrupt the memory holding the\ncode data. This will usually show itself as only receiving the following error\nafter a while.\n\n```\nWARNING:ChipWhisperer Scope:Timeout in OpenADC capture(), no trigger seen! Trigger forced, data is invalid.\n```\n\nThis will persist even if you restart your measurement. If you want do normal\nmeasurements again, you need to reset the FPGA.\n\n```python\nftarget = cw.target(\n\tscope, cw.targets.CW305,\n\tbsfile='V:/hardware/CW305_DesignStart/CW305_DesignStart.bit',\n\tfpga_id='100t', # or the other board\n\tforce=True\n)\n```\n\n## Hardware modifications\nIn this example, there is minimal FPGA logic alongside the Arm target. The\nCW305 FPGA has lots of space remaining for your ideas! Our\n[DesignStartTrace](https://github.com/newaetech/DesignStartTrace) project\nis one example of what you can do, and gives an worked-out example of adding\nconfiguration registers and setting them from Python.\n\nKeep in mind that whenever a new bitstream is generated in Vivado, the \n`make_mmi_file.tcl` and `make_prog_files.bat` scripts must be re-run.\n\n\nAdditionally, if the address map changed, then the BSP also needs to be\nregenerated.\n\nFinally, update the FPGA bitfile with the `make_prog_files.bat` script.\n\n\n# Debugging\nThe three LEDs located above the SMA connectors on the bottom of the CW305\nprovide some limited visibility into the target status:\n- Red LED (LED7): Cortex clock, should be periodically toggling. If it's\n  constantly on or off, then the Cortex has no clock. The clock is generated\n  on the CW305 itself. Check your modifications to the `Clocks_and_Resets`\n  block.\n- Green LED (LED5): Cortex reset signal, should be off.\n  If it's on, then the Cortex reset signal hasn't been released. Again,\n  check your modifications to the `Clocks_and_Resets` block.\n- Blue LED (LED6): UART activity. Should see fast bursts of activity\n  whenever there is UART traffic. Check your modifications to the\n  `axi_uartlite_0` block. Inactivity can also be caused by mistakes in the\n  bitfile update flow.\n\nOn the CW312-A35, these map to LED1/2/3 respectively on the CW313.\n\nIf you get clean FPGA and software builds but yet the target isn't\nresponding, here is a list of possible causes:\n- Did you [update the MMI file?](#update-mmi-file)\n- Did you try [resetting the target?](#fpga-and-target-resets)\n- There are a number of scripts which move the executable generated by Keil\n  towards its final destination in the FPGA bitfile; make sure these all ran\n  cleanly:\n     - Keil build outputs are in `v:/software/CW305_DesignStart/Build_Keil/objects`\n     - the `make_hex_a7.bat` script creates `bram_a7.elf` and `bram_a7.hex`\n       in `v:/software/CW305_DesignStart/Build_Keil` and in\n       `v:/hardware/CW305_designstart`\n     - the `make_prog_files.bat` script creates the final bitfile:\n       `v:/hardware/CW305_DesignStart/CW305_DesignStart.bit`\n- If the CFGITCMEN[1:0] inputs aren't properly assigned, the processor will\n  attempt to fetch the program from the wrong place.\n- If the modifications to the `Clocks_and_Resets` blocks weren't done\n  properly, clocks and resets may not be getting propagated correctly. Note\n  that there are several internal resets, not just the one which is routed\n  to LED5.\n\nIf you're still stuck, try simulation, ILAs, or routing internal signals to\nthe JP3 header. Simulation is probably the right choice, unless you enjoy\n[FPGA hell](https://zipcpu.com/blog/2017/05/19/fpga-hell.html). DesignStart\ncomes with a Verilog testbench (see\n`v:/docs/arm_cortex_m3_designstart_fpga_xilinx...pdf`), but you will need to\nmodify it to account for the changes we have made to the design.\n\nOnce you've determined that there are no hardware issues, you can move on to\nsoftware. If you have an external debugger, connect it to the the JTAG or\nSWD signals which have been routed to the JP3 header (refer to the\n`CW305_designstart.xdc` constraints file for details).\n\nDebugging has been successfully tested using a Segger J-link Plus, using\neither the JTAG or SWD interface, with speed set to \"auto\".\n\nOn the CW312-A35, set CW JTAG select switches 1-4 to \"on\" to connect the\n\"FPGA Jaytag\" header to the DesignStart soft-core JTAG.\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnewaetech%2Fcw305-arm-designstart","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnewaetech%2Fcw305-arm-designstart","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnewaetech%2Fcw305-arm-designstart/lists"}