Vivado HLS from ROM

This link breaks down how to read in a csv (or other data file type) and gives instructions about how to convert each of the files to header files that can be synthesized by the HLS tool. The problem is, if this is all done by the Zedboard, it would mean that converting to a header file from a csv would have to be executed one by one because the function to do so includes fopen, fscanf, and fclose (which cannot be synthesized by hls because they are too high level.

https://forums.xilinx.com/t5/High-Level-Synthesis-HLS/HLS-ROM-from-file/td-p/654517

So from digging the answer might be in one of many places but for now my ideas are the following:

1. Place the function that will convert the csv to a header file in the testbench function in HLS. 
1. This function will create the header file that can be read by the "to be synthesized source file" in HLS. The pre-filter, pass1, and pass2 can all be pipelined from there although I doubt that will speed up the process at all. If the idea is to process in parallel, then the part we want to pipeline would be the conversion (more files at once)
2. Of course one would have to look at the time it takes to receive one sample data set (that 2x502) file that comes from the scope (I will learn later this week or next how exactly this is done and have a better idea of what direction to go). If the time it takes to create one pulse is similar to the time it takes to convert that data into a header file that can be read by HLS code, then we are in good shape because the processor will be able to keep up with the incoming data. However, if the data coming in exceeds the speed of the testbench conversion into a header file then we are in trouble, and this would seem like a good place to begin parallel processing but we are again met with the problem of fopen, fscanf, and fclose not being able to be synthesized. 
1. So I plan on figuring out the times for each of these processes and figuring out what the best course of action is. The fear is that the data will come in much quicker thatn the processor can process, and we will be in trouble...............BUT that's why I'm thinking of other ways to solve this problem from the beginning!
2. Extract the fopen, fscanf, and fclose functions from the stdio.h library and see if the lower level code that creates those functions can be synthesized.
1. It would seem as though, at some level, the code HAS to be able to be synthesized, but you know, nothing ever works correctly, so there could be a third option on this blog by next week.