High-level synthesis

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?
Reply to
Benjamin Couillard
Loading thread data ...
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 to
Rob Gaddi
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 to
Theo Markettos
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 to
gtwrek
Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard:
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 to
A.P.Richelieu
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 to
Theo Markettos
or
ght
ht
lt
For DSP I created my own Matlab scripts to create automated VHDL files (fil ters or ROMs). I worked great but was only semi-portable. I.e. it needed so me degree of customization for each application.
Reply to
Benjamin Couillard
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.
formatting link

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 to
Rob Gaddi
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 to
gtwrek
I did the same in VHDL about 10 years ago. It worked well for a medium-size d system. It was based on a code snippet posted by Jonathan Bromley on comp .lang.vhdl
Reply to
Benjamin Couillard
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
Reply to
A.P.Richelieu
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.
Reply to
Kevin Neilson
"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.
Reply to
Kevin Neilson
Den 2019-03-23 kl. 05:43, skrev A.P.Richelieu:
Had a brief look at your stuff at
*
formatting link

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
Reply to
A.P.Richelieu
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/
Reply to
Jan Coombs
I read on the myhdl discourse that there seems to be a problem with the myhdl owner not maintaining myhdl the way a proper project owner should. Care to comment on that?
--
Svenn
Reply to
Svenn Are Bjerkem
I write my models in Matlab so I'm going to stick with that. Once the model works in Matlab, I used functions I have to generate very low-level Verilog for things like Galois field matrix multipliers.
Reply to
Kevin Neilson
Yes, this is a problem. The BDFL found time to consolidate progress to a 0.10 release. The team look capable, but their interests will likely diverge/fork if the leadership does not improve.
What else combines the constructional power of the Python ecosystem, with simulation speed equal to other free tools [1], and spits out Verilog or VHDL?
Jan Coombs
--
[1] Performance - MyHDL is fast! 
http://www.myhdl.org/docs/performance.html
Reply to
Jan Coombs
lot of Matlab that generates Verilog. I wish I didn't have to, but that's the way it is.
myhdl owner not maintaining myhdl the way a proper project owner should. C are to comment on that?
The reason I don't write assembly these days is that gcc does the job for m e *and* that there is a certain safety that gcc will not disappear because some leadership wanders off to more interesting projects. This has happened to "fast" tools in the past, and it will happen to "fast" tools in the fut ure. When I decide to put a massive effort into learning something, I would like to know where I am heading. The current situation at myhdl is rocking my trust in it.
It is not that I am not willing to look into new ways of resolving my devel opment and verification tasks. I am looking into both myhdl and cocotb[2] a nd I use ghdl as my simulator. cocotb managed to get their things together regarding the massive improvement in ghdl[3] on vhdl-2008, myhdl seem to st ill think iverilog is the only way to cosimulate in the FOSS world.
[2]
formatting link
[3]
formatting link
--
Svenn
Reply to
Svenn Are Bjerkem
Yep. Registers can have fields of types signed, unsigned, or bits. That generates VHDL records with named fields of types SIGNED, UNSIGNED, and STD_LOGIC_VECTOR (or STD_LOGIC for single bit fields) and functions to translate the records to/from a STD_LOGIC_VECTOR the size of the read/write bus, as well as procedures to modify a structured register from a write data bus that has byte enables.
If you use the high-level API (suitable for "I want to implement these registers on flops", not for "I want to implement a large BRAM for this.") you wind up with the entire thing in a t__regfile, which is a record type where each register (or register array) is a field. So you wind up using things like regfile.ctl.enable to interface with your logic.
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.