EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

High-level synthesis

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - High-level synthesis

Goto page 1, 2  Next

Benjamin Couillard
Guest

Thu Mar 21, 2019 7:45 pm   



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?

Rob Gaddi
Guest

Thu Mar 21, 2019 9:45 pm   



On 3/21/19 11:40 AM, Benjamin Couillard wrote:
Quote:
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.

Theo Markettos
Guest

Thu Mar 21, 2019 9:45 pm   



Benjamin Couillard <benjamin.couillard_at_gmail.com> wrote:
Quote:
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)

gtwrek
Guest

Thu Mar 21, 2019 9:45 pm   



In article <1f6821b7-29e5-4c99-813f-74a4577a75e9_at_googlegroups.com>,
Benjamin Couillard <benjamin.couillard_at_gmail.com> wrote:
Quote:
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

A.P.Richelieu
Guest

Fri Mar 22, 2019 5:45 am   



Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard:
Quote:
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

Theo Markettos
Guest

Fri Mar 22, 2019 12:45 pm   



A.P.Richelieu <aprichelieu_at_gmail.com> wrote:
Quote:
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

Benjamin Couillard
Guest

Fri Mar 22, 2019 3:45 pm   



Le jeudi 21 mars 2019 15:56:02 UTC-4, Theo Markettos a écrit :
Quote:
Benjamin Couillard <benjamin.couillard_at_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.

Rob Gaddi
Guest

Fri Mar 22, 2019 5:45 pm   



On 3/21/19 9:37 PM, A.P.Richelieu wrote:
Quote:
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


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.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

gtwrek
Guest

Fri Mar 22, 2019 6:45 pm   



In article <q731fb$lbr$1_at_dont-email.me>,
Rob Gaddi <rgaddi_at_highlandtechnology.invalid> wrote:
Quote:
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

Benjamin Couillard
Guest

Fri Mar 22, 2019 10:45 pm   



Le vendredi 22 mars 2019 13:40:58 UTC-4, gtwrek a écrit :
Quote:
In article <q731fb$lbr$1_at_dont-email.me>,
Rob Gaddi <rgaddi_at_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


I 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

A.P.Richelieu
Guest

Sat Mar 23, 2019 5:45 am   



Den 2019-03-22 kl. 17:11, skrev Rob Gaddi:
Quote:
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.

AP

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.


Thank You,
I will have a look.
I was discussing this with the guy that has generated the FPGA
code for my current project, and he suggested an XML based
approach instead of C.
If I was going that route, to start from a description and
generate both C and VHDL, I would probably use a JSON format,
since they are so much easier to read.

In my mind the best way is to start off with the C driver.
If you like us are running Linux & U-Boot, then you
have an API for the driver, which needs to be followed.

The H/W implementation of all the peripherals I have seen basically
suck, and the C driver implementer has to overcome all the deficiencies
forced upon him/her by the chip designers.

The proper approach is to start with the API and then
figure out how to implement this in a driver in the most efficient way.

spi_xfer(peripheral SPI, uint8_t src, size_t size, enum spi_flags flags)
{
SPI->START = flags; // Activate CS on request
strncpy(SPI->FIFO, src, size);
SPI->STOP = flags; // Deactivate CS on request
}

Once I have the driver figured out, I already have the headers,
so I do not want to create XML to regenerate what I already have.

AP

Kevin Neilson
Guest

Sun Mar 24, 2019 3:45 am   



I wouldn't recommend pursuing HLS. It's a siren call. It will just bring you trouble. My rule is this: when I feel like the tools have successfully mastered mid-level synthesis, I'll give HLS another look. One who cannot yet crawl cannot claim to run.

Kevin Neilson
Guest

Sun Mar 24, 2019 3:45 am   



"Hardware Construction Language": that's a good phrase. I write a lot of Matlab that generates Verilog. I wish I didn't have to, but that's the way it is.

A.P.Richelieu
Guest

Sun Mar 24, 2019 5:45 am   



Den 2019-03-23 kl. 05:43, skrev A.P.Richelieu:
Quote:
Den 2019-03-22 kl. 17:11, skrev Rob Gaddi:
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.

AP

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.


Thank You,
I will have a look.
I was discussing this with the guy that has generated the FPGA
code for my current project, and he suggested an XML based
approach instead of C.
If I was going that route, to start from a description and
generate both C and VHDL, I would probably use a JSON format,
since they are so much easier to read.

In my mind the best way is to start off with the C driver.
If you like us are running Linux & U-Boot, then you
have an API for the driver, which needs to be followed.

The H/W implementation of all the peripherals I have seen basically
suck, and the C driver implementer has to overcome all the deficiencies
forced upon him/her by the chip designers.

The proper approach is to start with the API and then
figure out how to implement this in a driver in the most efficient way.

spi_xfer(peripheral SPI, uint8_t src, size_t size, enum spi_flags flags)
{
   SPI->START = flags;        // Activate CS on request
   strncpy(SPI->FIFO, src, size);
   SPI->STOP  = flags;        // Deactivate CS on request
}

Once I have the driver figured out, I already have the headers,
so I do not want to create XML to regenerate what I already have.

AP


Had a brief look at your stuff at

* https://github.com/NJDFan/register-maps

This is mainly to do address decoding, right?
Do you have any support for the actual fields inside the registers?
That is a primary function I would be looking for.

I can actually see the use of such tool for me,
if my C struct parser generates the XML (or JSON)
for an intermediate representation.

BR
AP

Jan Coombs
Guest

Sun Mar 24, 2019 8:45 am   



On Sat, 23 Mar 2019 19:45:06 -0700 (PDT)
Kevin Neilson <kevin.neilson_at_xilinx.com> wrote:

> "Hardware Construction Language": that's a good phrase. I write a lot of Matlab that generates Verilog. I wish I didn't have to, but that's the way it is.

Could you construct and simulate with MyHDL? The verilog
would then be just a simple export. [1]

Jan Coombs
--
[1] MyHDL - From Python to Silicon!
http://www.myhdl.org/

Goto page 1, 2  Next

elektroda.net NewsGroups Forum Index - FPGA - High-level synthesis

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map