Hi, I have a little problem with running PYRTL. When I source oss cad suite, pipelineC forces me to specify part and I can't go with PYRTL flow.

But if I run pipelineC without oss, pipelineC runs PYRTL flow but then GHDL is not detected and it fails to run ;o

any ideas? quick fixes?

As @suarezvictor has pointed out - wouldnt it be nice to not have to specify WIRE for things - and have the tool do it all? :smirk:

Currently global variables are identical in functionality to static local variables. They are associated with a single function only. Even though global variables are in the global scope, they cannot be directly used by multiple functions. Global variables are locked to a single function right now.

Currently WIRE's are the work around for this. A global variable is declared but special WIRE/clock crossing functions are used to make clear where writes to the global vs reads to global are occurring.

Why is it needed to know when writes and reads occur? Well lets get into why this issue has few layers to it...

for variables declared as const, never generate registers for the pipeline (just wires) This will ease the job of the synth tool and be easier than tracking if the variables changes (and makes syntax and purpose of functions more clear)

I wrote a model of FPGA delays. It works by parsing the logs at ./path_delay_cache/vivado/xc7a35ticsg324-1l/syn For each entry it calculates the timing depending on the type of operation and bit widths involved, and RMS error overall, dumping the results

Example on the current database: Count: 339 , minimum delay (ns): 1.117 , RMS error (ns): 0.41

The function is called like this: estimate_int_timing("XOR", [16, 16])

returns None if estimation is not available. NOTE: only integer support

TODO: calculate coefficients automatically from the database, and generate the samples by calling the synth project for various kind of operations and bit sizes

In the Setup instructions, the open source synthesis integration instructions call for the user to manually specify the paths for Yosys and NextPNR. This is really sub-optimal, and can make user patches more annoying to review and/or merge.

A more flexible solution would be to allow more options that can leverage industry-standard flows such as environment variables, i.e. $YOSYS_PATH, $NEXTPNR_PATH, etc.

These scripts are used to generate Vitis hls IP's that transfer data to/from pipelineC generated IP. Streaming interfaces are used as communication channel. PipelineC ip is packaged as .XO and connected with Vitis at linking stage.

Since operator overloading is easily supported for compile as regular C++ it seems like a reasonable idea to make possible for user types now in plain-C PipelineC. Thanks for the push @suarezvictor!

Maybe?

typedef struct ....my_struct_t;
#pragma OVERLOAD * my_struct_t my_mul_op
my_struct_t my_mul_op(my_struct_t lhs, my_struct_t rhs)
{
...
}

Or does this feature wait for PipelineC++ rewritten with clang tools etc?

Current clock crossings take into account clock ratios to buffer and/or require fifos if the clock domains are not the same.

Create a way of declaring a wire-always clock domain crossing (always a wire, not just when same clock domain - for all domain crossings).

Ex. If user instantiated a PLL inside the design (instead of typically outside top level). Or if user did the slow clock via counters thing to produce internal slow changing 'clock' signal.

Copy pasting the snippet of docs explaining the current situation:

https://github.com/JulianKemmerer/PipelineC/wiki/Running-the-Tool

If the tool is stopped while running, upon next start it attempts to restart where it left off. Good for large designs / long synthesis sweeps. But bad for other yet-to-be-resolved reasons: Stopping the tool after code parsing completes means the code will not be parsed again - delete your_file.c.parsed from within SYN_OUTPUT_DIRECTORY directories if code is modified after parsing. Stopping the tool during synthesis creates a failing synthesis run log - delete that log file from it's SYN_OUTPUT_DIRECTORY before trying again. If all else fails, try removing the SYN_OUTPUT_DIRECTORY before running the tool as a sanity check. Ex.rm -r ~/pipelinec_syn_output/*; ./src/pipelinec

Want a way to auto remove this directory (or continue using it correctly) as needed

As opposed to fancier C++ style syntax for bit slicing, ex bits<5,2>(x) as suggested from https://github.com/JulianKemmerer/PipelineC/discussions/32 (trying to replace current bit manip syntax...)

Do something that is immediately parseable by pycparser and also overloadable by full C++ software compilers (as evidenced by other C++ HLS tools using syntax like below):

uint32_t x;
...
uint1_t b = x[3]; // Fourth bit of x(31 downto 0)
uint16_t y = x(15, 0); // (15 downto 0) 16b slice of x

Thanks @Quarky93 !

Code like so:

#include "intN_t.h"
#include "uintN_t.h"

#pragma MAIN test
uint32_t test()
{
  uint32_t a_const_array[3];
  // Dummy logic to use array...
  int32_t i;
  uint32_t sum;
  for(i=0;i<3;i+=1){
    sum += a_const_array[i];
  }
  return sum;
}

With a_const_array default initialized to zeros produces incorrect VHDL syntax when used in the array dereferenced like a_const_array[i]

VAR_FOR_main_c_l112_c3_32e3_ITER_0_CONST_REF_RD_uint32_t_uint32_t_3_0_d41d_main_c_l114_c12_2cd5_return_output := (others => to_unsigned(0, 32))(0);

Work around: Init each element

uint32_t a_const_array[3] = {0, 0, 0};

produces vhdl assignments of individual u32s

VAR_FOR_main_c_l113_c3_149c_ITER_0_BIN_OP_PLUS_main_c_l114_c5_0eb6_left := to_unsigned(0, 32);
     VAR_a_const_array_0_main_c_l109_c12_ca56_0 := resize(to_unsigned(0, 1), 32);

Likely to do with how null array isnt same constant as a literal zeros that would be each array element....

Ex. global wire 'point': This makes it so you cant drive point.x from one main function, and point.y from another - both drive the entire wire, not just pieces.

Currently for basic things like adders ex. 32 bits is divided by the slices specified [0.5] = slice into two pieces = two 16b stages

First this is annoying because [0.499] is the same slicing (etc w/ close FP values) but still gets a different file, file name etc, blegh

Also its important to know how many bits per stage as being used. As in https://github.com/JulianKemmerer/PipelineC/issues/46 and https://github.com/JulianKemmerer/PipelineC/issues/48 and https://github.com/JulianKemmerer/PipelineC/issues/45 we want to know what hardware is produced by the synthesis tool - some bits per stage implement better than others, etc.

The FIFO_FWFT implementation is correct in its use of valid+ready handshake signaling clock by clock.

However because of the weird way that the implementation uses its 2 cycle latency BRAM, asserting flow control ready=0 one cycle later causes 2 cycles of pause/valid=0 output data in a way that typical streams of data/FIFOs do not do...

Fix this because it can be a corner case folks get stuck on if not strictly following handshake signals...

Related to allowing global variables to be top level inputs or outputs https://github.com/JulianKemmerer/PipelineC/issues/123

Allow special clock enable and reset signals marked this way too maybe?

Otherwise, work around like in the graphics repo work - simply using a MAIN top level input port ex. pixel(uint1_t clock) that renders a pixel_clock input wire and marking it with the CLK_MHZ pragma as a clock doesnt work for all tools:

During internal runs of the tool all inputs have registers so timing paths are all sync. In this case the input clock is registered using itself as a clock and weird things happen...

At least apparently for some tools like Quartus, which, similar to https://github.com/JulianKemmerer/PipelineC/issues/137, seem unable to use get_nets for the internal net name that isn't registered as the source of the clock for create_clock in the timing constraints. The internal clock net is also connected as an output port. Quartus can apply a clock to this output port with get_ports - but the clock constraint does not reach the interior of the design - internal registers,etc that are using the internal 'copy' of the clock wire are all still unconstrained/not reached by the output port create clock constraint.

Vivado however is able to define a proper internal clock net usingcreate_clock with get_nets on the intended top level clock signal (and seems to ignore preceding funny clock input register business).