Import Upstream version 20090922

1 files changed, 40 insertions, 0 deletions

diff --git a/doc/intermediate_code.txt b/doc/intermediate_code.txt
index c64870f..e76698c 100644
--- a/doc/intermediate_code.txt
+++ b/doc/intermediate_code.txt
@@ -103,3 +103,43 @@ or
 annotation specification, that can have an implementation dependant effect.
 An implementation may restrict annotation specifications to be present only
 at limited places inside the intermediate code.
+
+
+===================
+= Foreign signals =
+===================
+
+The treatment of foreign signals is implementation spefic. However, since I 
+constantly forget the reason why fauhdli does it that way, here are some
+notes how it is done:
+
+For a foreign signal that is being read by VHDL, a driver is created which
+will get connected via glue_vhdl.
+for a foreign signal that is written to from VHDL, a foreign driver is 
+created. The value of this driver is only passed later on 
+via glue-vhdl, after all non-foreign signals have been handled.
+
+The reason is the following:
+  Propagating the value via a glue-vhdl means to basically execute a 
+  foreign process. This must happen at a discrete step in the 
+  simulation cycle to guarantuee correctness.
+
+Resolution functions:
+It's not possible to use VHDL resolution functions for foreign signals,
+as the aforementioned semantics imply that actually resolution is performed
+by the foreign signal (Consider a foreign signal that is read from and 
+written to in VHDL, it has one or more foreign drivers, which forwards 
+VHDL changes to glue_vhdl and one hidden driver, which actually represents
+the signal value).
+
+If resolution was possible by taking all drivers, resolve them to the signal
+value and forward the result, then a lock to a dominant value could occur:
+As an example, both the foreign signal and the VHDL counterpart have all
+driving values set to 'Z', so all signal values are also 'Z'. If now VHDL
+sets one driver to '0', this one will be dominant. It's passed on to
+the foreign signal which will also set it's value to '0', like the VHDL value.
+As a result the hidden foreign input driver for the VHDL signal will have the
+driving value '0'. Setting the driver back to 'Z' which caused the transition
+to '0' will still locally resolve to '0', due to the other "segment" of the 
+bus having been forced to '0'. And that's why it all comes down to using 
+only the foreign side for resolutions.