diff --git a/docs/faq.rst b/docs/faq.rst
index a6ccbdd..751de34 100644
--- a/docs/faq.rst
+++ b/docs/faq.rst
@@ -54,6 +54,20 @@ has syntax to do this:
 This is lesser-known syntax, but still very well supported by synthesis
 tools, and is the recommended way to handle this.
 
+... What if I want to assign it to a bit-vector?
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Assigning the hwif struct to a bit-vector is strongly discouraged. This tool makes
+no guarantees regarding the field ordering of the hwif structure, so doing so
+should be considered functionally dangerous.
+
+That said, if you still need to do this, it is still trivially possible to
+without requiring packed structs. Instead, use the SystemVerilog streaming operator:
+
+.. code:: systemverilog
+
+    my_packed_vector = {<<{hwif_out}};
+
+
 ... Why are unpacked structs preferred?
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 In the case of the hardware interface ports, unpacked structs help prevent
diff --git a/docs/hwif.rst b/docs/hwif.rst
index 07cfe03..3bf50db 100644
--- a/docs/hwif.rst
+++ b/docs/hwif.rst
@@ -49,3 +49,13 @@ For example, a simple design such as:
 
 For brevity in this documentation, hwif features will be described using shorthand
 notation that omits the hierarchical path: ``hwif_out..<feature>``
+
+
+.. important::
+
+    The PeakRDL tool makes no guarantees on the field order of the hwif structs.
+    For this reason, it is strongly recommended to always access struct members
+    directly, by name.
+
+    If using the SystemVerilog streaming operator to assign the hwif struct to a
+    packed vector, be extremely careful to avoid assumptions on the resulting bit-position of a field.