about_use_of_named_pipes.txt

2022.08.18

The use of FIFOs (named pipes) in this code is done as follows:
- App to VHDL:
    - clock
- VHDL to App:
    - DOs
    - LEDs (not yet implemented)
# The other signals are simulated with shared files that emulate digital signals one to one.
  A third approach, passing digital information as data inside the shared files, worked as well.
  win32file.CreateFile() blocked permanently because "other processes" retained the shared files,
  for that reason a straight-forward and platform-independent open() was used instead.

Note 1: using only shared files is possible but one CPU will be always at 100% polling the external clock.
        Instead, at least the external clock signal from the App shall be read in the VHDL code over a FIFO (named pipe) in order not to overload 1 core.
        Running e.g. the python App on Linux and the VHDL code in VIVADO on Windows is very easy when using only shared files (using named pipes can be complicated).
        For this you can do e.g.:
        Win11: share C:\\tmp\hw_sin_fwk on the network
        Linux: sudo mount -t cifs '\\<IP_of_Win11>\hw_sim_fwk' /tmp/hw_wim_fwk -osec=ntlmv2,username=<user_name>,file_mode=0777,dir_mode=0777,uid=<user_name>
               (to unmount type: sudo umount /tmp/hw_sim_fwk)

Note 2: in the case "App to VHDL" we don't use named pipes (FIFOs) for:
        - DIs
	- switches
	- buttons
	- reset
	- etc.
        because the "blocking" call on readline() will block the complete VHDL simulation, 
	even when the calls are done in different processes or modules!

Assumption: concurrency of processes in the VHDL simulator VIVADO 2022.1 does not have the same characteristics
            as concurrency of threads at the level of the operating system, at least for handling files/pipes.

TODO:
- investigate if this is a bug in VIVADO 2022.1 or a "hole" in the VHDL specification.
- test if the violation of "concurrency" when using two "normal" stimulus files in different
  processes simultaneously also occurs.
  This would mean e.g. that it is not possible to input several stimulus files simultaneously
  to different processes in a concurrent way, what is a "big constraint" but shows how powerful FPGA_HW_SIM_FWK is!
  Probably the same limitation will then occur with stdin, stdout and stderr.
- investigate how to read FIFO in VHDL without blocking. But this overrides the whole purpose of 
  using named pipes in the first place, which is to NOT poll anything but just wait blocking
  only the current process.
- Multithreaded Testbench? Is the worst-case-scenario for a solution something like SpinalHDL ?
  https://spinalhdl.github.io/SpinalDoc-RTD/dev/SpinalHDL/Simulation/threadFull.html
  https://spinalhdl.github.io/SpinalDoc-RTD/dev/index.html
  https://github.com/SpinalHDL/SpinalHDL
- even worse than SpinalHDL?
  https://newit.gsu.by/resources/Journals%5Cisdmag%5Carticles%5Cmultithread.htm
  https://patentimages.storage.googleapis.com/de/ac/6e/fa9deb26b7b2ee/CA2397302C.pdf
- use-case: app and VHDL-Simulation run on different systems (Linux, Windows):
  try to connect remote named pipes between Linux and Windows (?). Note: this seems to be complicated, e.g. security configuration. 
  Several people recommend using sockets instead.