commit 6b0a58992c8c8bf0b1ca5d7c7b69380d02215a24
author Philipp Wagner <phw@lowrisc.org> Wed Nov 04 14:44:31 2020 +0000
committer Philipp Wagner <mail@philipp-wagner.com> Thu Nov 05 21:14:14 2020 +0000
tree 35ccd91e2e747054ac032bdcebfca11a2accabe5
parent 80cc823fbca6b62b71d851b95ddd6f8f490d480d

[otbn/dif] Use void* instead of uint32_t* for memcpy() parameters

Before, we used uint32_t* for in and out arguments to OTBN's instruction
and data memory access functions; we did this to indicate an alignment
requirement on the Ibex side, and to indicate the required data
granularity, which are multiples of 32b words.

This commit switches to use `void*` instead, on the following grounds:
* There is no alignment requirement for this data, it gets passed on to
  a function which also takes a `void*` argument and deals with
  unaligned data properly.
  (It is, of course, more efficient to provide aligned data; that's up
  to the caller, however.)
* The granularity is checked within the function by checking
  `len_bytes`.
* Being able to pass byte arrays into the instruction and data memory write
  functions makes code significantly easier to read (compared to passing
  uint32_t items): OTBN data is often a wide number, e.g. a 1024b
  number, passed in as little-endian data. Writing such a large number
  in uin32_t integers in code makes the code hard to read, as one needs
  to read each integer byte-wise from back to front, move on to the next
  integer, and do the same again.

For example, to write the number 0x0706050403020100 in code:

```
uint32_t a[2] = { 0x03020100, 0x07060504 };
uint8_t b[8] = { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 };
```

On uint8_t* vs void*: void* is used by the underlying memcpy() functions
and slightly more convenient to use, so I chose that (it's also
consistent with expectations from normal memcpy()).

Signed-off-by: Philipp Wagner <phw@lowrisc.org>