Replaced the term core with hart (#30)

zilsd.adoc

@@ -87,7 +87,7 @@ When using `x0` as `src` of SD or C.SDSP, the entire 64-bit operand is zero —
 
 === Fault Handling
 
-In implementations that crack Zilsd instructions for sequential execution, correct execution requires addressing idempotent memory, because the core must be able to handle traps detected during the sequence. The entire sequence is re-executed after returning from the trap handler, and multiple traps are possible during the sequence.
+In implementations that crack Zilsd instructions for sequential execution, correct execution requires addressing idempotent memory, because the hart must be able to handle traps detected during the sequence. The entire sequence is re-executed after returning from the trap handler, and multiple traps are possible during the sequence.
 
 If a trap occurs during the sequence then xEPC is updated with the PC of the instruction, xTVAL (if not read-only-zero) updated with the bad address if it was an access fault and xCAUSE updated with the type of trap.
 
@@ -116,7 +116,7 @@ From a software perspective the load/store pair instructions appears as:
 
 An implementation may have a requirement to issue a load/store pair instruction to non-idempotent memory.
 
-If the core implementation does not support Zilsd instructions to non-idempotent memories, the core may use an idempotency PMA to detect it and take a load or store access fault exception in order to avoid unpredictable results.
+If an implementation of a hart does not support Zilsd instructions to non-idempotent memories, the hart may use an idempotency PMA to detect it and take a load or store access fault exception in order to avoid unpredictable results.
 
 Software should only use these instructions on non-idempotent memory regions when software can tolerate the required memory accesses being issued repeatedly in the case that they cause exceptions.