Busy times and a sneak peek at the future

It's been about a month that I've written a blog post about what's going on here at Synflow. Time to share! Truth is we have been quite busy, both Nicolas and I, on time-consuming tasks:

  1. raising money: until we have paying customers, we need funds! We secured a first 60 k€ regional (no interest) loan, and we are in the process of getting an equivalent sum from our bank. This is short-term only, we will soon be looking for more capital. Business angels, strategic investors, feel free to contact us!
  2. providing support for our users, and working on improving the presentation on our website (it appears that people have trouble understanding what it is that we do!)
  3. expanding our network and getting feedback from experienced designers in the industry
  4. building the next version of Synflow Studio. Since this is almost exclusively what I spend my days doing, I describe in this post what is the current status and what you can expect from it. Spoiler: it's something big!

About Synflow Studio

Current status first: at this point the Studio is kind of torn apart. Why? I have started implementing several feature requests from users at once:

  • textual description of network in Cx
  • support of parameters tasks/networks (a.k.a. generics)
  • support for reset customization (no reset, synchronous, asynchronous)
  • much better support for integration of existing RTL components
  • generate cleaner/simpler code

Several of these changes have required heavy, deep changes to the models we use. To give you an idea, I remove a whole model (that's about 20 Java classes) that was used throughout the code base. We used to depend on another project for the model that defines the Intermediate Representation; we no longer depend on it, which has allowed me to make large-scale modifications very quickly to support the use cases mentioned above.

Is graphic gone?

For the moment, yes. From now on, a network is defined textually in C~. Later on, when other pieces start to connect together, I'll bring back the graphical editor and adapt it to the new Cx network model. It means that you will need to convert graphical designs to textual networks; I may provide an automated converter to do that if there is sufficient demand.

Why are you going textual?

This is an interesting question. As mentioned above, this is a huge undertaking, so why do we bother? First, support for network description in Cx is a feature that has been requested by prospects or users several times. Second, we have seen the limits of graphical description, especially when dealing with repetitions or as soon as the number of connections increases too much: these are cases when you start spending a lot of time beautifying the design instead of just making it. Third, textual description is much more flexible than graphical when it comes to dealing with parameters (and I have some very nice ideas related to that, so we can have some compile-time safety with runtime flexibility, more on that in a later post). Fourth, did I mention that this was requested by users and prospects? :-)

Having a textual description of networks also make manual description of pipelines much easier (as you'll see below). And I have a couple of crazy ideas for higher-level descriptions, that has the potential to completely change how we integrate/interact with IP. This is still just an idea, so it should be taken with a grain of salt, but it's about composing pieces of code together. If successful this will allow the description of high-level structures/behavior such as dynamic memory allocation, linked list, etc. in Cx 8-)

So why did you go graphic in the first place?

Because existing ways of describing connections are just too verbose. In VHDL/Verilog you need to add intermediate wires between tasks: a wire is connected to one task's output and another task's input. SystemC uses the same principle, just with C++ syntax like sc_signal<sc_int<16> > which is hardly an improvement IMO. Also our background with dataflow process networks was using graphical editors, so naturally we started the product by implementing a graphical editor :-) We still believe a graphical editor is a nice asset, especially to help understanding/documenting an IP core, as well as for doing system-level design.

What does it look like?

Here is an example of a Cx file that defines a network implementing a simple, two-stages pipeline:

package com.synflow.examples;

import com.synflow.mem.SinglePortRAM;
network N {
  ports { in u8 a, b, c; out u16 dout; }

  ram = new SinglePortRAM(16, 10);

  t1 = new task {
    void run() {
      t2.sum.write(a.read + b.read);
    }
  };

  t2 = new task {
    port in u9 sum;
    void run() {
      dout.write(sum.read * c.read);
      ram.address.write(4); // read address 4
    }
  };
}

This example declares a network that contains a "ram" instance of a task named "SinglePortRAM", as well as two anonymous tasks instantiated as "t1" and "t2". Anonymous tasks can refer to the ports of other instances, as well as the network's ports directly. I have added a second syntax for port declaration (ports { }), that is handy when declaring a lot of ports. A Cx file can now declare many tasks and networks (as opposed to only one single task before). That example does not show connections between named tasks, or generic parameters, multiple clocks, custom resets because I am still designing the syntax, I will be back with more details soon :D

What about the other features you mentioned?

Parameters will allow clients to use Synflow Studio to create generic IP cores. I had to replace the type system (which used fixed-size types) to allow this! Integration of existing RTL components should make it very easy to have a Cx design incorporating RTL IP. Code generators now include a "code cleaning" pass that removes all the useless intermediate variables, so the generated code is much more "hand-written-like" than before. I am also updating the generators to leverage the target's type system's semantics to generate prettier code. Multiple clocks were supported before, it is just a matter of adding them to Cx (incidentally, we will be able to support multi-clocked third-party RTL). Custom resets are necessary for supporting all use cases (no resets for memory inference, synchronous or asynchronous resets depending on guidelines/synthesis tools/target platform).

All of this is still very much ongoing work that will be available as nightly builds as soon as I can get one code generator back on track (first one will be Verilog), so you will be able to watch the changes as they are happening, and try it out early. I will give updates as I make headway on specific features!

Thank you for reading this far, and stay tuned!