definelicht / hlslib Goto Github PK

The OpenCL header needs thorough doxygen documentation of all classes and member functions to make their semantics more clear.

Hey ‪Johannes!

I'm still using your hlslib with great success for my work, so once again thank you!

I am currently trying to reduce the amount of warnings I get from my build.
Some of the remaining warnings are stemming from hlslib, in particular from the following two places:

Resource pragma

#pragma HLS Resource seems to have been deprecated in 2020.2, so the following code produces warnings like

WARNING: [HLS 207-5510] 'Resource pragma' is deprecated, and it will be removed in future release. 
It is suggested to replace it with 'bind_op/bind_storage pragma'.: 
/home/dev/hlslib/include/hlslib/xilinx/Stream.h:500:9

Possible solution

  Stream(char const *const name) : Stream<T, 0, storage>(name, depth, storage) {
    #pragma HLS INLINE
#if !defined(__VIVADO_HLS__) || defined(__VITIS_HLS__)
    #pragma HLS STREAM variable=this->stream_ depth=depth
    if (storage == Storage::BRAM) {
      #pragma HLS bind_storage variable=this->stream_ type=FIFO impl=BRAM
    } else if (storage == Storage::LUTRAM) {
      #pragma HLS bind_storage variable=this->stream_ type=FIFO impl=LUTRAM
    } else if (storage == Storage::SRL) {
      #pragma HLS bind_storage variable=this->stream_ type=FIFO impl=SRL
    }
#endif
  }

However, this might have to be wrapped in conditions checking the Vitis HLS version...

Unused parameter

During synthesis, the following code produces "unused parameter" warnings:

WARNING: [HLS 207-5301] unused parameter 'name': /home/dev/hlslib/include/hlslib/xilinx/Stream.h:354:35

Possible solution

#ifndef HLSLIB_SYNTHESIS
  void set_name(char const *const name) {
    name_ = name;
#else
  void set_name(char const *const) {
#endif
  }

Thanks for merging my PR so quickly!

I just ran into the next issue 😄

ARM64 support

As we are moving along with the project, we are trying to run embedded designs.
For that, we would need host code compiled for ARM64, but it seems like hlslib does not support that yet:

What would need to be done to support ARM64?
It looks like we would need the right runtime and possibly the floating point libraries, but I really don't fully understand this part.

When trying to run vitis_hls, the compiler fails because hls::stream is embedded in hlslib::Stream:

ERROR: [HLS 214-141] hls::stream object('stream_') inside aggregate type 'Stream<float, 1, hlslib::Storage::Unspecified>' is not supported: include/hlslib/xilinx/Stream.h:527

Most likely, this is not actually a problem, but has been disallowed explicitly for some reason. There's no good fix for this without dropping the object oriented interface entirely, so this issue should be raised with Xilinx.

Hi,

I hope you're having a nice day.
I felt obliged to share my project which uses hlslib, as it helped a lot and simplified complicated procedures immensely. I cannot imagine developing the same project without hlslib and cmake.
https://github.com/salehjg/DGCNN-on-FPGA/tree/host_opt
( The project aims to accelerate a point cloud classifier network (dgcnn) using an FPGA and its preprint soon will be ready. )

ps:
We also have used gemm_hls in our design and both of the papers for hlslib and gemm_hls are cited.

Hi,
I use gemm_hls project. Recently, I installed Xilinx RunTime and Deployment Target Platform of U250 by following step1 to step3 in the website https://www.xilinx.com/products/boards-and-kits/alveo/u250.html#gettingStarted . When I run

platforminfo -l

it shows an error

Error parsing platform file: /opt/xilinx/platforms/xilinx_u250_gen3x16_xdma_4_1_202210_1.xpfm
Line number:16. Mandatory element missing
ERROR: Caught an internal exception: failed to parse the XPFM file

I think it might be the reason that I failed to run the cmake command

-- Querying default clock for xilinx_u250_gen3x16_xdma_4_1_202210_1.
Exception: failed to parse the XPFM file
CMake Error at CMakeLists.txt:129 (string):
string begin index: -1 is out of range 0 - 174

-- Querying Vitis platform for MatrixMultiplication.
Exception: failed to parse the XPFM file
-- Configuring incomplete, errors occurred!

In fact, xilinx_u250_gen3x16_xdma_4_1_202210_1.xpfm is in path "/opt/xilinx/platforms/xilinx_u250_gen3x16_xdma_4_1_202210_1/xilinx_u250_gen3x16_xdma_4_1_202210_1.xpfm". However, Vitis could not find it even though I copied it to "/opt/xilinx/platforms" manually.

I am wondering if there are any necessary operations to make xpfm file visible to Vitis. And I use Vitis 2021.1 on Ubuntu20.04.

​

Hi,

I have watched the "Productive Parallel Programming for FPGA with High Level Synthesis" on youtube and I found it be very useful, thank you for posting it! I'm trying to run the examples on my machine but I have encountered the warning and error shown below when synthesizing any example that includes the use of hlslib (this is from Example 4). I'm using vivado hls 2019.2 on Windows. I have tried setting the CFLAG to -std=c++0x or -std=c++11, when doing so too many errors arise as shown in the second picture below. When I open the c++0x_warning.h file the warning is mentioning c++11. I've spent quite some time trying to solve this issue to no avail.

The C simulation runs successfully though.

Thank you for your help.

Best Regards,
Sarah

"
Starting C synthesis ...
C:/Xilinx/Vivado/2019.2/bin/vivado_hls.bat C:/Users/Sara/AppData/Roaming/Xilinx/Vivado/Example4/Example4/csynth.tcl
INFO: [HLS 200-10] Running 'C:/Xilinx/Vivado/2019.2/bin/unwrapped/win64.o/vivado_hls.exe'
INFO: [HLS 200-10] For user 'Sara' on host 'lenovo-sara' (Windows NT_amd64 version 6.2) on Fri Nov 05 14:09:18 +1100 2021
INFO: [HLS 200-10] In directory 'C:/Users/Sara/AppData/Roaming/Xilinx/Vivado'
Sourcing Tcl script 'C:/Users/Sara/AppData/Roaming/Xilinx/Vivado/Example4/Example4/csynth.tcl'
INFO: [HLS 200-10] Opening project 'C:/Users/Sara/AppData/Roaming/Xilinx/Vivado/Example4'.
INFO: [HLS 200-10] Adding design file 'Example4/Example4/Example4.cpp' to the project
INFO: [HLS 200-10] Adding test bench file 'Example4/Example4/Test.cpp' to the project
INFO: [HLS 200-10] Opening solution 'C:/Users/Sara/AppData/Roaming/Xilinx/Vivado/Example4/Example4'.
INFO: [SYN 201-201] Setting up clock 'default' with a period of 10ns.
WARNING: [HLS 200-40] Cannot find library 'C:/Xilinx/Vivado/2019.2/common/technology/xilinx/Virtex-7/Virtex-7.lib'.
WARNING: [HLS 200-40] Cannot find library 'xilinx/Virtex-7/Virtex-7'.
INFO: [HLS 200-10] Setting target device to 'xc7vx485t-ffg1157-1'
INFO: [SYN 201-201] Setting up clock 'default' with a period of 10ns.
INFO: [SCHED 204-61] Option 'relax_ii_for_timing' is enabled, will increase II to preserve clock frequency constraints.
INFO: [HLS 200-10] Analyzing design file 'Example4/Example4/Example4.cpp' ...
WARNING: [HLS 200-40] In file included from Example4/Example4/Example4.cpp:1:
In file included from Example4/Example4/Example4.h:3:
In file included from Example4/Example4/hlslib/xilinx/Stream.h:11:
In file included from C:/Xilinx/Vivado/2019.2/win64/tools/clang/bin..\lib\clang\3.1/../../../include/c++/4.5.2\condition_variable:34:
C:/Xilinx/Vivado/2019.2/win64/tools/clang/bin..\lib\clang\3.1/../../../include/c++/4.5.2\bits/c++0x_warning.h:31:2: error: This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
#error This file requires compiler and library support for the upcoming
^
1 error generated.
C preprocessor failed.
while executing
"source C:/Users/Sara/AppData/Roaming/Xilinx/Vivado/Example4/Example4/csynth.tcl"
invoked from within
"hls::main C:/Users/Sara/AppData/Roaming/Xilinx/Vivado/Example4/Example4/csynth.tcl"
("uplevel" body line 1)
invoked from within
"uplevel 1 hls::main {*}$args"
(procedure "hls_proc" line 5)
invoked from within
"hls_proc $argv"
Finished C synthesis.
"

This project seems very interesting, since I am trying to get up to speed developing SW for FPGA.
However I am using Vitis 2020.2 and had some problems to get it find my Vitis Installation.
Has the FindVitis.cmake been tested for 2020.2?

When trying to run cmake .. -DVITIS_ROOT=path\to\xilinx\Vitis\2020.2 I get the error:

-- Could NOT find Vitis (missing: Vitis_COMPILER Vitis_HLS Vitis_INCLUDE_DIRS Vitis_LIBRARIES Vitis_FLOATING_POINT_LIBRARY Vitis_VERSION Vitis_MAJOR_VERSION Vitis_MINOR_VERSION Vitis_PLATFORMINFO)
-- Could NOT find IntelFPGAOpenCL (missing: IntelFPGAOpenCL_AOCL IntelFPGAOpenCL_AOC IntelFPGAOpenCL_INCLUDE_DIRS IntelFPGAOpenCL_LIBRARIES IntelFPGAOpenCL_RPATH IntelFPGAOpenCL_VERSION IntelFPGAOpenCL_MAJOR_VERSION IntelFPGAOpenCL_MINOR_VERSION)

Also I am interested only in the Vitis part, so is the IntelFPGA part strictly necessary or can I disable it?

Hi, I was trying to use the library with Vivado HLS 2019.2 and it's surprising that I probably cannot run cosim_design independent of cynth_design from my tcl scipt.

So every time I am calling cosim_design it is forcing csynth_design, even if I had previously run succesfully csynth_design. So I have the obvious issue of how to set the -DHLSLIB_SYNTHESIS flag, since for cosim_desing it had to be undefined and for csynth_design it has to be defined.

Wondering if you have face this issue already and there is a quick workaround.
thx
--d

I am trying to migrate my SDAccel project from GUI to CMake buildsystem.
While trying to figure out how to use your CMake script, I noticed something weird was happening.

I have installed SDx2017.4 and when I run cmake .., in function sdaccel_target, the if-statement that detects SDAccel versions, evaluates false so as a result, CMake script does not execute required commands to generate *.xclbin files needed for emulation or hardware targets.

if(((${SDAccel_MAJOR_VERSION} LESS 2018) AND (${SDAccel_MINOR_VERSION} LESS 3)) OR ${SDAccel_MAJOR_VERSION} LESS 2017)

The problem is with:
(${SDAccel_MINOR_VERSION} LESS 3)
Obviously, for 2017.4, the minor version is 4.

With all the changes in the recent releases of SDAccel, I am not sure if this is intentional and the CMake script does not support 2017.4 or I am missing something obvious.

I appreciate your quick response on this.
Thanks.

Hi, Thanks for your advice on gemm, now I'm working on the gemm_hls project to run it on the U50 board . The gemm_hls project can be synthesized on U250, which uses DDR memory, but U50 uses HBM, what do I need to do on hlslib to run the code on U50? Thank you!

Hi, hlslib is an interesting project, thanks for the great work!

Would you have plans to support Vitis 2022.1 and 2022.2?

Hey, I'm having an issue trying to place templated functions in the dataflow method. For example, in the following usage, HLSLIB_DATAFLOW_FUNCTION(func<a,b,c>, in, out ); , the HLSLIB_DATAFLOW_FUNCTION macro changes it to func<a(b,c>,in,out); Have any recommendations to fix this?

Thanks

Hi,

I think the below function in Stream.h should have the type bool not void.

Regards,
Sarah

void WriteOptimistic(T const &val) {
#pragma HLS INLINE
#ifndef HLSLIB_SYNTHESIS
#pragma HLS INLINE
return WriteOptimistic(val, depth_);
#else
return WriteOptimistic(val, std::numeric_limits::max());
#endif
}

Intro

Happy (belated) New Year!

I am still using hlslib frequently, so once again thanks for your work.

Problem

Currently I am using AXI4-Stream interfaces between kernels, and that works as expected with the hlslib::Stream class.
However, I am now using an IP that requires a full AXI4-Stream interface, and thus I use ap_axiu to make HLS synthesize the required side channels.
For some reason the build fails when using hlslib::Stream, but works if I just replace those streams using ap_axiu with hls::stream.
There seem to be no useful messages in the logs as to what the cause is, it just states

Failed to build kernel(ip) debug, see log for details: <path>/_x/debug_hw/debug/vitis_hls.log

Said log only tells me

INFO: [HLS 200-111] Finished Source Code Analysis and Preprocessing: CPU user time: 27.32 seconds. CPU system time: 1.27 seconds. Elapsed time: 27.56 seconds; current allocated memory: 206.791 MB.
INFO: [HLS 200-777] Using interface defaults for 'Vitis' flow target.
ERROR: [HLS 200-1715] Encountered problem during source synthesis

There are also no pertinent earlier warnings.

Question

Would you happen to know what the cause could be?
If not, I can try to put together a minimal failing example, but I will need some time for that.

In DataPack, the data is stored in an ap_uint of bit width 8*<bytes in T>.

However, on an FPGA this introduces significant storage inefficiency. I want to store an array of fixed-point data in the URAM of the FPGA. I have some liberty to decide the bit-width of a single data element. Considering that it is best to use power-of-two shaped accesses, we want to choose a bit width so that some power-of-two elements fit into 72 bits. This means we can choose 9, 18, 36 or 72 as the bit-width for best efficiency in the URAM. In our case, we were able to make do with 9bits.

My first try was thus doing something like the following:

hlslib::DataPack<ap_fixed<9, 1>, 8> array[N];
#pragma HLS bind_storage variable=array type=RAM_1P impl=URAM

Due to line 31 in the code I cited above however, the DataPack actually internally uses a uint<128> to store the 8 fixed-point numbers, not uint<72>.
This of course means I need twice as much URAM for this type of array.

To solve this for my case, I made my own tiny class (taking the important parts from your DataPack):

template<int width>
class TightPack {
 public:
  using Data_t = ap_fixed<9, 1>;
  static constexpr int kWidth = width;
  #if defined(HLSLIB_SYNTHESIS)
  static constexpr int kBits = Data_t::width;
  #else
  static constexpr int kBits = 8 * sizeof(Data_t);
  #endif
 private:
  ap_uint<width*kBits> data_;
  using Pack_t = ap_uint<kBits>;
 public:
  Data_t Get(int i) const {
    // Just like regular DataPack
  }

  void Set(int i, weight_t val) {
    // Just like regular DataPack
  }
};

The only difference (aside from a lot of missing functionality) is the calculation of kWidth, and I made that depend on whether we are in synthesis or not.
It is also specialized for ap_fixed.

Ideally, I would like to make a small template specialization of your DataPack class instead, as in

template<int width>
class DataPack<ap_fixed> {
  // Only change kWidth implementation
};

However, this would mean I would need to copy the entire DataPack class content in there, defeating the purpose of specialization.
Maybe putting a helper class like the following in between might improve this:

template<typename T>
WidthCalculator {
 public:
  static constexpr int value = 8  * sizeof(T);
};

DataPack could use this class to calculate kBits in line 31 like:

  static constexpr int kBits = WidthCalculator<T>::value;

Then I could subclass the WidthCalculator to my liking, for example

template<>
template<int W, int I>
WidthCalculator<ap_fixed<W, I> {
 public:
  static constexpr int value = W;
};

and use DataPack<ap_fixed<9, 1>, 8> for optimal storage in URAM (and BRAM for that matter).

Actually, might this specialization (and similar ones for the other fixed width types in HLS) be important enough to include in the library itself?

It would be nice to add the full() and empty()methods, so that we have less changes in the code when we use hlslib to wrap hls streams (i.e. instead of having to change to Isfull() and isEmpty()). This addition to Stream.h is working for me:

  // Compatibility with Vivado HLS interface
  bool empty() {
    #pragma HLS INLINE
    return IsEmpty();
  }

  bool full() {
    #pragma HLS INLINE
    return IsFull();
  }

thanks
--d

Hey, hope you're doing well!

Intro

I will be holding a (very brief) presentation at a small FPGA conference in Japan (sorry, info all in Japanese).
As it is just 5 minutes, I figured I would talk about the simulation capabilities of HLSLIB, in particular the dataflow/stream part since I did some work on that with you and am using it extensively in my project.
It seems easy enough to explain, and was very helpful during debugging and is something I think people should be using over the default hls::stream behavior.

Issue

In the presentation, I want to show issues with the defaul hls::stream class, namely

• that it deadlocks when it shouldn't due to it being single-threaded,
• that it doesn't deadlock when it should due to streams being of infinite depth

Now, I was defining some very simple example code, stuff like

void pipe_in(const float in_data[N], stream_t& in_stream_1, stream_t& in_stream_2) {
  for (int i=0; i<N; ++i) write(in_data[i]);
  for (int i=0; i<N; ++i) write(in_data[i]);
}

where I define stream_t as either hlslib::Stream or hls::stream. As you can see, I am using the ::write interface so that I can just write the function once, as opposed to the ::Push interface (which I normally prefer).
Good thing hlslib::Stream also conforms to that! 👍
However, it seems to not only be supporting the interface, but also to simulate the behavior of hls::stream, namely infinite depth:

This means that hlslib will not deadlock when it really should when using this interface - is that intended?\

Suggestion

I think it may be reasonable to have hlslib::Stream::Push and hlslib::Stream::write behave exactly the same, and only keep the latter for the desired interface compatibility.

Hi,
I have been trying to use hlslib to create a dataflow scheme using template functions and noticed that template functions are not supported.

It is important not to have any wrappers for manually instantiated template functions, so the final user can easily change the number of PEs(or blocks or whatever...) from the CMake script.

I was hoping something like this would be possible:

constexpr int myParameter = 10;
For(int i=0; i<unitCount; i++){
#pragma hls unroll
    HLSLIB_DATAFLOW_FUNCTION( 
             MyTemplate<i*myParameter>(.....));
}

Templating the whole cpp file using cmake would be too messy and I do not know a way to do the same thing using compile time c++ or preprocessors.

Any suggestions?

Christian Lutzweiler has suggested making wrapper types and utility functions supporting custom bitwidths. Features could include:

• Portable custom bitwidth type (Xilinx uses ap_uint, OpenCL doesn't support it, i++ might have something).
• Utility functions for determining bitwidths (e.g., using hlslib::ConstLog2).
• Conversion functions between different bitwidths, potentially emitting compile-time errors if not explicitly overwritten for unsafe conversions.

I'm connecting my kernel to an AXI4 stream of the platform.
This works with the plain hls::stream class, but I would prefer to use the superior hlslib::Stream.
Since it is on the interface, I would like to specify something like

#pragma HLS INTERFACE axis port=to_fft.stream_

However, stream_ is a protected member so I cannot do that.
I probably don't need to specify the pragma at all, but I like to be verbose with those.

Making the stream public might not be the cleanest thing to do, but it would help in this case.
Thoughts?

The DataPack class from hlslib appears to support arrays whose size is defined at compile time. Is there a way to pass a struct containing a pointer to a dynamically sized POD array to an HLS kernel?

We wrote up a hello world code that passes a struct as a void* then casts it to a struct inside the kernel function:

https://github.com/cwsmith/hls_sandbox/blob/919c2113935b44b59989ff7c3d01cca2c678738a/hello.cc#L35

This will compile and run in emulation mode (see the README.md). I suspect that accessing the pointer inside the ints struct is invalid inside the kernel without it having a port assigned to it. Is that correct?

Hi,
When I run the gemm_hls project, the system reported an error:"No platform found in path /home/***/Xilinx/Vitis/2021.1/platforms", how can I solve the problem? Thank you!

cmake ../ -DMM_DATA_TYPE=float -DMM_PARALLELISM_N=32 -DMM_PARALLELISM_M=8 -DMM_MEMORY_TILE_SIZE_N=512 -DMM_MEMORY_TILE_SIZE_M=512

-- Using user defined Xilinx Runtime (XRT) directory "/home//Xilinx/XRT-master/build/Debug/opt/xilinx/xrt".
-- Looking for CL_VERSION_2_2
-- Looking for CL_VERSION_2_2 - found
-- Found OpenCL: /usr/lib/x86_64-linux-gnu/libOpenCL.so (found version "2.2")
-- Found Vitis: /home//Xilinx/Vitis/2021.1/bin/v++
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Looking for sgemm_
-- Looking for sgemm_ - found
-- A library with BLAS API found.
-- Querying default clock for xilinx_u250_gen3x16_xdma_3_1_202020_1.
No platform found in path /home/***/Xilinx/Vitis/2021.1/platforms
CMake Error at CMakeLists.txt:124 (string):
string begin index: -1 is out of range 0 - 0

-- Querying Vitis platform for MatrixMultiplication.
No platform found in path /home//Xilinx/Vitis/2021.1/platforms
CMake Warning at hlslib/cmake/FindVitis.cmake:438 (message):
Xilinx platform xilinx_u250_gen3x16_xdma_3_1_202020_1 was not found.
Please consult "/home//Xilinx/Vitis/2021.1/bin/platforminfo -l" for a
list of installed platforms.
Call Stack (most recent call first):
CMakeLists.txt:198 (add_vitis_program)

Setup:

Ubuntu 18.04
Intel OpenCL SDK 18.1
cmake version 3.17

Scenario:

cmake -Bbuild -GNinja .
-- The C compiler identification is GNU 7.5.0
-- The CXX compiler identification is GNU 7.5.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Could NOT find Vitis (missing: Vitis_COMPILER Vitis_HLS Vitis_INCLUDE_DIRS Vitis_LIBRARIES Vitis_FLOATING_POINT_LIBRARY Vitis_VERSION Vitis_MAJOR_VERSION Vitis_MINOR_VERSION)
-- Found IntelFPGAOpenCL: /home/rnd/intelFPGA/18.1/hld/bin/aocl
-- Configuring done
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
stdc++_PATH (ADVANCED)
linked by target "RunJacobi2D.exe" in directory /home/rnd/dev/third_parties/hlslib/intel_test

-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.

It would be nice to have a way to pass a list of events that need to complete before a Kernel can start executing or a Buffer operation is executed

Ref: https://www.khronos.org/registry/OpenCL//sdk/2.2/docs/man/html/clEnqueueTask.html
(this is the C API, but I assume the same applies to the C++ one)

ConstLog2 is defined as

For an input of (for example) 16 this yields 5, which is wrong I believe. It should be 4.

A correct definition might be:

constexpr unsigned char ConstLog2(unsigned long val) {
  return val < 2 ? 0 : 1 + ConstLog2(val >> 1);
}

This would also return 0 for an input of 0, and correctly return 0 for 1, and also correct values for all higher input values I think.

Hi, I got the following error when calling IsEmpty() method after the HLSLIB_SYNTHESIS is set.

../../include/hlslib/xilinx/Stream.h:453:12: error: 'this' argument to member function 'empty' has type 'const hls::stream<int>', but function is not marked
      const
    return stream_.empty();

The reason of this error is that a non-const method empty() is called from a const method IsEmpty(). I would like to know if the const qualifier is really necessary for this method.