It's been about 3 years since I've done any *serious* FPGA work. I used mostly VHDL or sometimes my own Matlab scripts to create automated VHDL files. I would like to know if anyone has used High-level synthesis recetnly for *real* work and if so, would they recommend that people learn it?
High-level synthesis
Started by ●March 21, 2019
Reply by ●March 21, 20192019-03-21
On 3/21/19 11:40 AM, Benjamin Couillard wrote:> It's been about 3 years since I've done any *serious* FPGA work. I used mostly VHDL or sometimes my own Matlab scripts to create automated VHDL files. > > I would like to know if anyone has used High-level synthesis recetnly for *real* work and if so, would they recommend that people learn it? >I definitely actively do *serious* FPGA work. I use VHDL, I testbench in VHDL, and every time I see the FPGA companies try to push me into high-level synthesis I can't quite see what the point is. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●March 21, 20192019-03-21
Benjamin Couillard <benjamin.couillard@gmail.com> wrote:> It's been about 3 years since I've done any *serious* FPGA work. I used > mostly VHDL or sometimes my own Matlab scripts to create automated VHDL > files. > > I would like to know if anyone has used High-level synthesis recetnly for > *real* work and if so, would they recommend that people learn it?I think it depends a lot on your application area. If what you do is DSP-style compute, you might be able to use HLS. It might save writing some VHDL, although if you're good at writing VHDL there might not be much in it. If your problem doesn't look much like DSP, I think it'll be more difficult to bend HLS to your will. Theo (my problems rarely look like DSP, so I don't use it)
Reply by ●March 21, 20192019-03-21
In article <1f6821b7-29e5-4c99-813f-74a4577a75e9@googlegroups.com>, Benjamin Couillard <benjamin.couillard@gmail.com> wrote:>It's been about 3 years since I've done any *serious* FPGA work. I used mostly VHDL or sometimes my own Matlab scripts to create automated VHDL files. > >I would like to know if anyone has used High-level synthesis recetnly for *real* work and if so, would they recommend that people learn it?Like the other posters - I user Verilog and SystemVerilog. HLS is still niche, with few good use-cases - contrary to how much the industry is still struggling to define it as the next big thing in EDA. I've written elsewhere - the problem with today's HLS solutions is the language choice, and target audience. Currently, that's C, and C like languages, targetting software folks. Both are the wrong choices. If the industry ever get's around to creating an HLS synthesis solution for code written in SystemVerilog - targetting the hardware designer - then I'll be the first in line. Until then it'll remain a niche solution - no matter how many new emails flood my inbox indicating it's the newest, bestest thing... Regards, Mark
Reply by ●March 22, 20192019-03-22
Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard:> It's been about 3 years since I've done any *serious* FPGA work. I used mostly VHDL or sometimes my own Matlab scripts to create automated VHDL files. > > I would like to know if anyone has used High-level synthesis recetnly for *real* work and if so, would they recommend that people learn it? > > >We are working on a system where we connect an FPGA and a CPU. The FPGA will implement almost 20-30 peripherals. The CPU will run Linux, and will need a driver for each type of peripheral. The Linux driver for each peripheral type will contain a main header file, and a file describing the user interface (I.E: the peripheral registers) A register could look like: typedef struct uart_mode_s { uint32_t bits:4; uint32_t parity:1; uint32_t odd:1; uint32_t encoding:2; uint32_t baud:24; } uart_mode_t; I use the register header file as input to a Python program to generate the register in VHDL. The Python program will generate a package containing the register with a std_logic_vector, and functions which will convert to and from a "record" so I can use the high level view of the register in VHDL. If I change the C header file in the driver, then the VHDL code will also change, due to dependencies in the build. Plan to have another Python program which will take a CSV file and use the contents to instantiate peripherals, and to generate the interface to the processor, including the address decoding. (Perhaps a JSON file will be better, though) This allows me to adopt to changing requirements and save a lot of time as well as keeping the driver and the peripheral in sync. I know others that do it the same way. AP
Reply by ●March 22, 20192019-03-22
A.P.Richelieu <aprichelieu@gmail.com> wrote:> I use the register header file as input to a Python program to generate > the register in VHDL. The Python program will generate a package > containing the register with a std_logic_vector, and functions which > will convert to and from a "record" so I can use the high level view > of the register in VHDL.That sounds more like what others call a 'Hardware Construction Language', rather than HLS. In your case, it sounds like you're doing basic 1:1 transformations - C structure to a bundle of wires, Python declaration to VHDL declaration, etc. You're writing Python not VHDL but you're still thinking like a hardware designer. That's not un-useful, but HLS is different in that the tool decides where the state should go - you describe your algorithm in (say) C or Matlab, and the tool decides to build a state machine from your declaration, but there are a large number of semantic transformations it goes through (for instance, unrolling loops and turning them into pipelined parallel hardware). The state in the output circuit bares only a passing resemblance to the state defined in the input C code. HLS has a much larger semantic gap to cross than a hardware construction language, which is why it doesn't work very well (IMHO). Theo
Reply by ●March 22, 20192019-03-22
Le jeudi 21 mars 2019 15:56:02 UTC-4, Theo Markettos a écrit :> Benjamin Couillard <benjamin.couillard@gmail.com> wrote: > > It's been about 3 years since I've done any *serious* FPGA work. I used > > mostly VHDL or sometimes my own Matlab scripts to create automated VHDL > > files. > > > > I would like to know if anyone has used High-level synthesis recetnly for > > *real* work and if so, would they recommend that people learn it? > > I think it depends a lot on your application area. > > If what you do is DSP-style compute, you might be able to use HLS. It might > save writing some VHDL, although if you're good at writing VHDL there might > not be much in it. > > If your problem doesn't look much like DSP, I think it'll be more difficult > to bend HLS to your will. > > Theo > > (my problems rarely look like DSP, so I don't use it)For DSP I created my own Matlab scripts to create automated VHDL files (filters or ROMs). I worked great but was only semi-portable. I.e. it needed some degree of customization for each application.
Reply by ●March 22, 20192019-03-22
On 3/21/19 9:37 PM, A.P.Richelieu wrote:> Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard: >> It's been about 3 years since I've done any *serious* FPGA work. I >> used mostly VHDL or sometimes my own Matlab scripts to create >> automated VHDL files. >> >> I would like to know if anyone has used High-level synthesis recetnly >> for *real* work and if so, would they recommend that people learn it? >> >> >> > > We are working on a system where we connect an FPGA and a CPU. > The FPGA will implement almost 20-30 peripherals. > The CPU will run Linux, and will need a driver for each type > of peripheral. > > The Linux driver for each peripheral type will contain a main header > file, and a file describing the user interface (I.E: the peripheral > registers) > > A register could look like: > > typedef struct uart_mode_s { > uint32_t bits:4; > uint32_t parity:1; > uint32_t odd:1; > uint32_t encoding:2; > uint32_t baud:24; > } uart_mode_t; > > I use the register header file as input to a Python program to generate > the register in VHDL. The Python program will generate a package > containing the register with a std_logic_vector, and functions which > will convert to and from a "record" so I can use the high level view > of the register in VHDL. > > If I change the C header file in the driver, then the VHDL code will > also change, due to dependencies in the build. > > Plan to have another Python program which will take a CSV > file and use the contents to instantiate peripherals, and > to generate the interface to the processor, including the address > decoding. (Perhaps a JSON file will be better, though) > > This allows me to adopt to changing requirements and save a lot of time > as well as keeping the driver and the peripheral in sync. > > I know others that do it the same way. > > APIf you haven't gotten too deep into writing your own code yet, you may want to check out a project I've been working on sporadically for a while now. https://github.com/NJDFan/register-maps There's also a more standard format for describing registers, IP-XACT, which like mine is XML-based. I found it impossibly obtuse to work with, but note it for the record. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●March 22, 20192019-03-22
In article <q731fb$lbr$1@dont-email.me>, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:>If you haven't gotten too deep into writing your own code yet, you may >want to check out a project I've been working on sporadically for a >while now. https://github.com/NJDFan/register-maps > >There's also a more standard format for describing registers, IP-XACT, >which like mine is XML-based. I found it impossibly obtuse to work >with, but note it for the record.IP-XACT is a solution looking for a problem. It's actually quite horrible, and a bad idea. From the camp of people who think "XML solves everything, more XML must be better..." Regarding the register-maps and autogeneration of RTL code, etc. We did that 10 years ago or so - but moved on to doing the opposite. We encode all the register information - offsets, masks, bit-field definitions, descriptions, etc directly in our code - NOT META COMMENTS - but SystemVerilog RTL code itself. We have catalog logic that checks for validity (overlaps, etc...), and other rules. A quick simulation job is run to generate (all sourced from the RTL) 1. Documentation (various formats - txt files, .csv) 2. Header files (*.h, .json, etc..) 3. other meta-data There's also simulation hooks included to look up address by name, etc, that ties right into the testbench setup. Works a charm. Machine generate RTL code always was ugly. Meta comment parsing was futzy. Now, it's the best of both worlds. Regards, Mark
Reply by ●March 22, 20192019-03-22
Le vendredi 22 mars 2019 13:40:58 UTC-4, gtwrek a écrit :> In article <q731fb$lbr$1@dont-email.me>, > Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote: > >If you haven't gotten too deep into writing your own code yet, you may > >want to check out a project I've been working on sporadically for a > >while now. https://github.com/NJDFan/register-maps > > > >There's also a more standard format for describing registers, IP-XACT, > >which like mine is XML-based. I found it impossibly obtuse to work > >with, but note it for the record. > > IP-XACT is a solution looking for a problem. It's actually quite > horrible, and a bad idea. From the camp of people who think "XML solves > everything, more XML must be better..." > > Regarding the register-maps and autogeneration of RTL code, etc. > We did that 10 years ago or so - but moved on to doing the opposite. > We encode all the register information - offsets, masks, bit-field > definitions, descriptions, etc directly in our code - NOT META COMMENTS - > but SystemVerilog RTL code itself. We have catalog logic that checks > for validity (overlaps, etc...), and other rules. A quick simulation > job is run to generate (all sourced from the RTL) > 1. Documentation (various formats - txt files, .csv) > 2. Header files (*.h, .json, etc..) > 3. other meta-data > > There's also simulation hooks included to look up address by name, etc, > that ties right into the testbench setup. > > Works a charm. Machine generate RTL code always was ugly. Meta > comment parsing was futzy. Now, it's the best of both worlds. > > Regards, > > MarkI did the same in VHDL about 10 years ago. It worked well for a medium-sized system. It was based on a code snippet posted by Jonathan Bromley on comp.lang.vhdl