It's 2016 and I still have to write out most of my code at very low levels of abstraction like I did ten years ago. Whenever I hear about a new tool that supposedly converts C to gates, I don't even look into it, because I can't even get Verilog to synth properly. My latest example: I needed to reduce an 12-bit number, mod-24. input [11:0] x; always@(posedge clk) xmod24 <= x%24; When I put this in Vivado, what do I get? 40 LUTs (plus some carry chains) and 10 levels of logic. TEN. Needless to say, that won't meet timing at 350MHz, especially when it involves getting on and off a bunch of little carry chains. So then I have to go down a level of abstraction: input [11:0]; // x%24 = 8*(floor(x/8)%3) + x%8 always@(posedge clk) xmod24 <= {x[11:3]%3, x[2:0]}; Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't have to instantiate primitives, like I still often do, even though it's 2016. Needless to say, I am not about to waste a bunch of time trying out any new "high-level synthesis" tools.
Mod-24: The State of High-Level Synthesis in 2016
Started by ●July 22, 2016
Reply by ●July 23, 20162016-07-23
On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:> It's 2016 and I still have to write out most of my code at very lowlevels of abstraction like I did ten years ago. Whenever I hear about a new tool that supposedly converts C to gates, I don't even look into it, because I can't even get Verilog to synth properly.> > My latest example: I needed to reduce an 12-bit number, mod-24. > > input [11:0] x; > always@(posedge clk) xmod24 <= x%24; > > When I put this in Vivado, what do I get? 40 LUTs (plus some carrychains) and 10 levels of logic. TEN. Needless to say, that won't meet timing at 350MHz, especially when it involves getting on and off a bunch of little carry chains.> > So then I have to go down a level of abstraction: > > input [11:0]; > // x%24 = 8*(floor(x/8)%3) + x%8 > always@(posedge clk) > xmod24 <= {x[11:3]%3, x[2:0]}; > > Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't haveto instantiate primitives, like I still often do, even though it's 2016.> > Needless to say, I am not about to waste a bunch of time trying out anynew "high-level synthesis" tools. I find it easy to ignore HLS, but I still suffer from it because it splits the tool vendors' development budget across multiple tools. I got all excited when I first heard about high level synthesis. Then I discovered that the language was C - hardly high level, and not particularly well suited to the sorts of things that FPGA coders need to do. It's not about making a better language though - it's about allowing non- FPGA people to do FPGA things, all in the name of market share. Allan
Reply by ●July 23, 20162016-07-23
On 7/22/2016 11:35 PM, Allan Herriman wrote:> On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote: > >> It's 2016 and I still have to write out most of my code at very low > levels of abstraction like I did ten years ago. Whenever I hear about a > new tool that supposedly converts C to gates, I don't even look into it, > because I can't even get Verilog to synth properly. >> >> My latest example: I needed to reduce an 12-bit number, mod-24. >> >> input [11:0] x; >> always@(posedge clk) xmod24 <= x%24; >> >> When I put this in Vivado, what do I get? 40 LUTs (plus some carry > chains) and 10 levels of logic. TEN. Needless to say, that won't meet > timing at 350MHz, especially when it involves getting on and off a bunch > of little carry chains. >> >> So then I have to go down a level of abstraction: >> >> input [11:0]; >> // x%24 = 8*(floor(x/8)%3) + x%8 >> always@(posedge clk) >> xmod24 <= {x[11:3]%3, x[2:0]}; >> >> Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't have > to instantiate primitives, like I still often do, even though it's 2016. >> >> Needless to say, I am not about to waste a bunch of time trying out any > new "high-level synthesis" tools. > > > I find it easy to ignore HLS, but I still suffer from it because it > splits the tool vendors' development budget across multiple tools. > > > I got all excited when I first heard about high level synthesis. Then I > discovered that the language was C - hardly high level, and not > particularly well suited to the sorts of things that FPGA coders need to > do. > It's not about making a better language though - it's about allowing non- > FPGA people to do FPGA things, all in the name of market share.I wouldn't say that. I know when I have heard using C for synthesis discussed it is more about being able to write the entire project in C and pick multiple options for the hardware vs. software trade off. I have no idea how realistic this might be. But I don't think it is about suddenly having a vast pool of talent to design hardware. -- Rick C
Reply by ●July 23, 20162016-07-23
I was pretty happy with Chisel for programming at a higher level. It's in Scala so it's a good blend of type safe but powerful and easy to write. It also catches silly Verilog errors like using an undeclared wire because of a typo. Writing tests was also easier compared to Verilog. There's a sample Risc V core as well with various number of stages. https://chisel.eecs.berkeley.edu/ On the down side, I did run into occasional issues with the framework and it's harder to debug in hardware since the compiled version is pretty obfuscated. The module inputs are there but other combinatorial glue logic and inner wires had random names.. tried to fix that but ran into framework issues with wire/register naming. It might be doable or I might have used it improperly but this was a hobby project and I did not have too much time to put into it. On Saturday, July 23, 2016 at 12:00:03 AM UTC-4, rickman wrote:> On 7/22/2016 11:35 PM, Allan Herriman wrote: > > On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote: > > > >> It's 2016 and I still have to write out most of my code at very low > > levels of abstraction like I did ten years ago. Whenever I hear about a > > new tool that supposedly converts C to gates, I don't even look into it, > > because I can't even get Verilog to synth properly. > >> > >> My latest example: I needed to reduce an 12-bit number, mod-24. > >> > >> input [11:0] x; > >> always@(posedge clk) xmod24 <= x%24; > >> > >> When I put this in Vivado, what do I get? 40 LUTs (plus some carry > > chains) and 10 levels of logic. TEN. Needless to say, that won't meet > > timing at 350MHz, especially when it involves getting on and off a bunch > > of little carry chains. > >> > >> So then I have to go down a level of abstraction: > >> > >> input [11:0]; > >> // x%24 = 8*(floor(x/8)%3) + x%8 > >> always@(posedge clk) > >> xmod24 <= {x[11:3]%3, x[2:0]}; > >> > >> Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't have > > to instantiate primitives, like I still often do, even though it's 2016. > >> > >> Needless to say, I am not about to waste a bunch of time trying out any > > new "high-level synthesis" tools. > > > > > > I find it easy to ignore HLS, but I still suffer from it because it > > splits the tool vendors' development budget across multiple tools. > > > > > > I got all excited when I first heard about high level synthesis. Then I > > discovered that the language was C - hardly high level, and not > > particularly well suited to the sorts of things that FPGA coders need to > > do. > > It's not about making a better language though - it's about allowing non- > > FPGA people to do FPGA things, all in the name of market share. > > I wouldn't say that. I know when I have heard using C for synthesis > discussed it is more about being able to write the entire project in C > and pick multiple options for the hardware vs. software trade off. I > have no idea how realistic this might be. But I don't think it is about > suddenly having a vast pool of talent to design hardware. > > -- > > Rick C
Reply by ●July 23, 20162016-07-23
I guess the good news is that I'll have a job for a few years at least. The machines are still pretty bad at my job.
Reply by ●July 23, 20162016-07-23
I remember going to a Celoxica Handel-C presentation long ago. As I recall they did try to convince managers that any software person who wrote C could also design FPGAs with Handel-C.
Reply by ●July 23, 20162016-07-23
On 7/23/2016 3:58 PM, Kevin Neilson wrote:> I remember going to a Celoxica Handel-C presentation long ago. As I recall they did try to convince managers that any software person who wrote C could also design FPGAs with Handel-C.Those people can also program FPGAs in VHDL. Did they try to say it would take no training? -- Rick C
Reply by ●July 23, 20162016-07-23
What about SDSoC Development Environment? Anyone with some hands on experience? I've seen a demo a few moths back and that looked promissing
Reply by ●July 25, 20162016-07-25
On Saturday, July 23, 2016 at 6:00:03 AM UTC+2, rickman wrote:> On 7/22/2016 11:35 PM, Allan Herriman wrote: > > On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote: > > > >> It's 2016 and I still have to write out most of my code at very low > > levels of abstraction like I did ten years ago. Whenever I hear about a > > new tool that supposedly converts C to gates, I don't even look into it, > > because I can't even get Verilog to synth properly. > >> > >> My latest example: I needed to reduce an 12-bit number, mod-24. > >> > >> input [11:0] x; > >> always@(posedge clk) xmod24 <= x%24; > >> > >> When I put this in Vivado, what do I get? 40 LUTs (plus some carry > > chains) and 10 levels of logic. TEN. Needless to say, that won't meet > > timing at 350MHz, especially when it involves getting on and off a bunch > > of little carry chains. > >> > >> So then I have to go down a level of abstraction: > >> > >> input [11:0]; > >> // x%24 = 8*(floor(x/8)%3) + x%8 > >> always@(posedge clk) > >> xmod24 <= {x[11:3]%3, x[2:0]}; > >> > >> Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't have > > to instantiate primitives, like I still often do, even though it's 2016. > >> > >> Needless to say, I am not about to waste a bunch of time trying out any > > new "high-level synthesis" tools. > > > > > > I find it easy to ignore HLS, but I still suffer from it because it > > splits the tool vendors' development budget across multiple tools. > > > > > > I got all excited when I first heard about high level synthesis. Then I > > discovered that the language was C - hardly high level, and not > > particularly well suited to the sorts of things that FPGA coders need to > > do. > > It's not about making a better language though - it's about allowing non- > > FPGA people to do FPGA things, all in the name of market share. > > I wouldn't say that. I know when I have heard using C for synthesis > discussed it is more about being able to write the entire project in C > and pick multiple options for the hardware vs. software trade off. I > have no idea how realistic this might be. But I don't think it is about > suddenly having a vast pool of talent to design hardware. > > -- > > Rick CI attended a Xilinx meeting a couple of weeks ago. They told us that the new tools (e.g SDSoc) are created for a new pool of engineers, e.g software engineers, architects, etc. So this new pool of engineers is also able to design FPGAs. They showed a "nice" slide with a very small pool of FPGA engineers and a very big pool of software engineers.
Reply by ●July 25, 20162016-07-25
On Sun, 24 Jul 2016 23:48:46 -0700, Devas wrote:> On Saturday, July 23, 2016 at 6:00:03 AM UTC+2, rickman wrote: >> On 7/22/2016 11:35 PM, Allan Herriman wrote: >> > On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote: >> > >> >> It's 2016 and I still have to write out most of my code at very low >> > levels of abstraction like I did ten years ago. Whenever I hear >> > about a new tool that supposedly converts C to gates, I don't even >> > look into it, because I can't even get Verilog to synth properly. >> >> >> >> My latest example: I needed to reduce an 12-bit number, mod-24. >> >> >> >> input [11:0] x; >> >> always@(posedge clk) xmod24 <= x%24; >> >> >> >> When I put this in Vivado, what do I get? 40 LUTs (plus some carry >> > chains) and 10 levels of logic. TEN. Needless to say, that won't >> > meet timing at 350MHz, especially when it involves getting on and off >> > a bunch of little carry chains. >> >> >> >> So then I have to go down a level of abstraction: >> >> >> >> input [11:0]; >> >> // x%24 = 8*(floor(x/8)%3) + x%8 always@(posedge clk) >> >> xmod24 <= {x[11:3]%3, x[2:0]}; >> >> >> >> Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't >> >> have >> > to instantiate primitives, like I still often do, even though it's >> > 2016. >> >> >> >> Needless to say, I am not about to waste a bunch of time trying out >> >> any >> > new "high-level synthesis" tools. >> > >> > >> > I find it easy to ignore HLS, but I still suffer from it because it >> > splits the tool vendors' development budget across multiple tools. >> > >> > >> > I got all excited when I first heard about high level synthesis. >> > Then I discovered that the language was C - hardly high level, and >> > not particularly well suited to the sorts of things that FPGA coders >> > need to do. >> > It's not about making a better language though - it's about allowing >> > non- >> > FPGA people to do FPGA things, all in the name of market share. >> >> I wouldn't say that. I know when I have heard using C for synthesis >> discussed it is more about being able to write the entire project in C >> and pick multiple options for the hardware vs. software trade off. I >> have no idea how realistic this might be. But I don't think it is >> about suddenly having a vast pool of talent to design hardware. >> >> -- >> >> Rick C > > I attended a Xilinx meeting a couple of weeks ago. They told us that the > new tools (e.g SDSoc) are created for a new pool of engineers, e.g > software engineers, architects, etc. So this new pool of engineers is > also able to design FPGAs. They showed a "nice" slide with a very small > pool of FPGA engineers and a very big pool of software engineers.Yay, Xilinx development money spent on another tool I'll never use. In the meantime, I'm using ISE for my Virtex 6 designs (which I have to support until 2020-something). Xilinx hasn't updated ISE since 2013. ISE will never support the current versions of VHDL or Verilog. Its bugs will never be fixed. I'm sure this makes sense to the people in marketing. Allan