PipelineC does not work on Apple Mac

[JulianKemmerer]

PipelineC has very few dependencies: python3 and a C preprocessor. This works out of the box on most Linux distros. However, it does not seem to work out of the box on Mac systems.

There has been confusion about cpp being the preprocessor or not, and what command line args it accepts: #166

But this will be the general issue where 'why doesn't PipelineC work on Mac?' can be discussed and hopefully fixed 🤞

[JulianKemmerer]

Forwarding on your insight here @playduck

This is likely an issue with Apple's clang not being 1:1 compatible with the cpp compiler.
Definitely a viable workaround, still a bit weird. Would be interesting to know why clang seems to have problems with its preprocessor.

Curious if like plain C text (missing pragmas :-/) gets through any further

typedef unsigned char uint1_t;
typedef unsigned long uint25_t;

uint25_t counter;

uint1_t led;


uint1_t blink()
{
  if(counter==(33333333-1))
  {
    led = !led;
    counter = 0;
  }
  else
  {
    counter += 1;
  }
  return led;
}

i.e. really making sure its just the preprocessor that is the problem...

As mentioned on that other issue, there are only a handful of places where cpp is hard coded in - so once we know the correct Mac equivalent of things should be easy to fix.

[playduck]

Back on native MacOS: the blink you provided compiles but of course it complains that it can't find a main function and suggests a #pragma.
Interestingly enough, when adding this pragma (and substituting main for blink) it also compiles:

python3.9 ./src/pipelinec ./examples/blink_test.c

Output directory: /.../PipelineC/pipelinec_output_blink_test.c_91336
================== Parsing C Code to Logical Hierarchy ================================
Parsing: /.../PipelineC/examples/blink_test.c
Preprocessing file...
Parsing C syntax...
Parsing non-function definitions...
Parsing derived fsm logic functions...
Doing old-style code generation based on PipelineC supported text patterns...
Elaborating function dataflow...
Elaborating dataflow of function: blink
Elaborating user function hierarchies down to raw HDL logic...
Doing obvious logic trimming/collapsing...
Writing generated PipelineC code from elaboration to output directories...
Writing cache of parsed information to file...
================== Writing Resulting Logic to File ================================
Writing log of integer module instances: /.../PipelineC/pipelinec_output_blink_test.c_91336/integer_module_instances.log
Writing VHDL files for all functions (before any added pipelining)...
Writing multi main top level files...
Writing the constant struct+enum definitions as defined from C code...
Writing global wire definitions as parsed from C code...
Writing output files before adding pipelining...
Output VHDL files: /.../PipelineC/pipelinec_output_blink_test.c_91336/vhdl_files.txt
================== Adding Timing Information from Synthesis Tool ================================
Need to set FPGA part somewhere in the code to continue with synthesis tool support!
Ex. #pragma PART "LFE5U-85F-6BG381C"

The only difference between the test version and the ./examples/blin.c is the #include statement and the typedefs.

I then removed the typedef's and replace it with an #include, such that it only reads #include "uintN_t.h".
This moved the error towards the uintN_t.h (same thing about some slash not being recognized).

Playing around in uintN_t.h I got it to compile by simply manually removing all comments (Lines 2-4, 9-10 and 104).
Furthermore keeping the comments but replacing the // line comments to /**/ block comments also compiled successfully (???)

[playduck]

Again I got the original blink (with original uintN_t.h) example to compile by changing the compiler to clang and explicitly running the preprocessor only with the -E flag:

C_TO_LOGIC.py:120 reads:

- def preprocess_file(filename, cpp_path="cpp", cpp_args=""):
+ def preprocess_file(filename, cpp_path="clang", cpp_args=["-E"]) -> str:

The same change also works identically in my ubuntu VM.
Other examples like fir.c still fail, presumably because, as you mentioned, cpp is still hardcoded in places.

[JulianKemmerer]

OK that sounds progress, appreciate the experimentation.

iirc the two types of preprocessor use in pipelinec are
'preprocesss this file' and 'ask preprocessor to list all the #include's in this file'.
I do believe clang -E sounds right as a preprocessor solution.

I am not familiar with equivalent for the includes in this file part c to logic py ~line 206
cpp -MM -MG

# Use cpp -MM -MG to parse the #include tree and get all files
# that need to be code gen'd again
# DOES NOT INCLUDE to-be-generated missing files
def get_included_files(c_filename):
    includes_list = GET_CPP_INCLUDES_LIST()
    includes_text = " ".join(includes_list)
    cmd = "cpp -MM -MG " + includes_text + " " + c_filename

[playduck]

I think I've got it mostly working!
All examples seem to finish with parsing/elaboration and writing.
Some examples then fail at the synthesis stage as I don't have Vivado or Quartus installed, but that's fine.

I've changed the default flags for the preprocess_text function (as well as preprocess_file):

- def preprocess_text(text, cpp_path="cpp", cpp_args=""):
+ def preprocess_text(text, cpp_path="clang", cpp_args=["-E"]):
     """Preprocess a file using cpp.
     filename:
         Name of the file you want to preprocess.
     cpp_path:
     cpp_args:
         Refer to the documentation of parse_file for the meaning of these
         arguments.
     When successful, returns the preprocessed file's contents.
     Errors from cpp will be printed out.
     """
 
     path_list = [cpp_path]
+   if isinstance(cpp_args, list):
+       path_list += cpp_args
+   elif cpp_args != "":
+       path_list += [cpp_args]

And in the other function simply replaced the cpp with clang:

 def get_included_files(c_filename):
     includes_list = GET_CPP_INCLUDES_LIST()
     includes_text = " ".join(includes_list)
-    cmd = "cpp -MM -MG " + includes_text + " " + c_filename
+    cmd = "clang -MM -MG " + includes_text + " " + c_filename

Definitely not the cleanest solution to put these in the default function args but it seems to work.

[JulianKemmerer]

Oh wow, well thats excellent to hear - getting all the way to synthesis sounds like fantastic progress!

Hmm, I feel like ive heard some struggles in the past getting FPGA tools working on Mac working generally ✊ Vivado, and even some open source options :-/

your changes can probably get merged in soon, look straight forward - but would love to hear if you try to install a synth tool, if it works all the way through. For ref some wiki notes https://github.com/JulianKemmerer/PipelineC/wiki/Running-the-Tool

[playduck]

To be fair working with FPGA's on Mac is neither productive, nor recommended nor for the sane.

Matter-of-fact I've not yet gotten a bitstream to build without VMs/Docker, so a full synth run is currently unlikely (And if the synth tools run in a VM I might as well run PipelineC there as well).
I've had some trouble with the yosys,GHDL and nextpnr flow, but don't remember where the roadblock was. I think I'll try that again.
I've also read that GoWin recently added Mac Support in their EDA, but I've never tried their tools/chips; Might give that a shot in the future too.

Getting PipelineC working on native MacOS is more for playing around and for simulating designs.

[JulianKemmerer]

😁
Yeah FPGA on Mac is not a very...common thing...for sure...

Any success in what OSS CAD SUITE offers? https://github.com/YosysHQ/oss-cad-suite-build

Re: pipelinec, I think next step is getting some logic to see if on Mac or not and changing out those two places where you fixed cpp use (idk generally could be a cpp then clang fall back as default all the time idk)

If you have any thoughts on how to structure that, happy to hear, can make a PR etc if you like