Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:42

    LarsAsplund on issue-833-type-generic-dict

    Disable dict get and set overlo… (compare)

  • 13:22

    LarsAsplund on issue-833-type-generic-dict

    Disable dict get and set overlo… (compare)

  • May 27 20:38
    bradleyharden edited #833
  • May 27 20:36
    bradleyharden opened #833
  • May 27 19:35

    LarsAsplund on issue-833-type-generic-dict

    Added generic type support to d… (compare)

  • May 26 07:18

    LarsAsplund on issue-833-type-generic-dict

    WIP: Added generic type support… (compare)

  • May 25 20:56

    LarsAsplund on issue-833-type-generic-dict

    WIP: Added generic type support… (compare)

  • May 21 20:18

    eine on master

    docs/about: fixed typo from "GD… (compare)

  • May 21 20:18
    eine closed #832
  • May 21 20:18
    eine milestoned #832
  • May 21 20:18
    eine labeled #832
  • May 21 20:18
    eine labeled #832
  • May 21 14:08
    std-max commented #824
  • May 21 13:40
    przemech reopened #832
  • May 21 13:39
    przemech closed #832
  • May 21 12:51
    przemech opened #832
  • May 20 08:09
    asicnet commented #808
  • May 20 08:07
    asicnet commented #808
  • May 20 08:04
    asicnet commented #808
  • May 20 07:42
    sibeov commented #741
Talon
@talonmyburgh

Hi all,
so I have what is possibly a very silly query but I am unsure how to go about solving it all the same.

I have a vhdl pkg with constants that govern the slv bit widths in my design. I cannot pass these bitwidths down via generics as these widths are specifications for bitwidths in an slv array.
The majority of my tests run with one bit width, but I have a few cases where I require a different one.
I want to know whether I can have a set up as follows:

  • start with the one bit width and its tb_configs.
  • run vu.main()
  • mangle the package to get the new bitwidth
  • re-compile the package.
  • add the tb_configs for this new bitwidth
  • remove the previous tb_configs
  • run vu.main() again.

Is this possible? I've not seen any way to remove tb configurations.

Lars Asplund
@LarsAsplund
@dasHorst99 To your first question: It looks like you're on the right path. In general I would also recommend looking at the tests that we use to verify the VCs. They are also open source and very much serves as executable documentation for the use of the tested VC. For example: https://github.com/VUnit/vunit/blob/master/vunit/vhdl/verification_components/test/tb_axi_lite_master.vhd
Lars Asplund
@LarsAsplund
@talonmyburgh I'm not sure I fully understand the context. Is it VHDL that prevents you from using generics or is it a policy that you should keep all parameterisation in a global package?
Talon
@talonmyburgh
@LarsAsplund I'm required to use older versions of VHDL (<2008) in order to use Vivado correctly. Early version do not allow for elements of an array to be unconstrained. So in my design we have an interface type with slv's in it that have bitwidths specified by a package. I cannot make use of this interface and pass down the bitwidths via generics.
dasHorst99
@dasHorst99
@LarsAsplund
Thank very much!
Unai Martinez-Corral
@umarcor
@talonmyburgh you can do VHDL 2008 -> ghdl synth -> VHDL 1993 -> Vivado, in order to use modern VHDL features without being limited by the poor support in Vivado.
Lars Asplund
@LarsAsplund
@talonmyburgh Ok, I see. What you have is basically several different but similar projects since the source code differs. If the package is a global common package it sounds like many files would depend on it and a lot of time would be spent on recompiling. If that is the case I would consider having different output paths for the different VUnit runs. One project has all the tests and the other project only have the tests with different widths.
Richard Head
@trickyhead_gitlab
@talonmyburgh What version of Vivado are you using? Vivado has very good synthesis of VHDL 2008 as of v2019.2. Unconstrained arrays have been working since before this.
Just dont bother with the simulator
Talon
@talonmyburgh
Thanks @LarsAsplund. Basically 2 run.py scripts with different outputs.
@trickyhead_gitlab, I unfortunately have to support a few versions of Vivado - from 2018 to 2021 (this is an open-source project with older hardware support required... sometimes as far back as ISE). We also support older versions of Quartus.
Thanks @umarcor , I must really look into this more. At present, CASPER (which is the organisation I am doing this HDL work for) compiles via Simulink (system generator and dsp builder). As a result, this move would require quite a bit of work but I'll bare it in mind.
Unai Martinez-Corral
@umarcor
@talonmyburgh is it https://github.com/casper-astro ?
I'm familiar with System Generator and, to a less extent, with HDL Verifier. I agree that introducing GHDL in that pipeline is not straightforward. However, it's something I want to document in the mid term.
I did use GHDL in a Vivado HLS -> VHDL -> GHDL -> Vivado workflow, which is not very different. But we are missing the tooling for the plumbing (see https://edaa-org.github.io/).
Talon
@talonmyburgh

Hi @umarcor that is it. A better starting place for information on the community is here.

Essentially, CASPER aims to provide a simple way for radio astronomers to deploy DSP backends for their radio telescopes. To keep things high-level, CASPER has some engineers in it's community create IP blocks in Simulink (or in my case HDL) for the scientists to make use of in the Simulink environment. The designs that the scientists create are largely simplified as Memory mapping, interfaces and ethernet cores are largely handled by the CASPER toolflow.

Up until now, all DSP for CASPER has been designed in Simulink. The several downsides to this are:

  1. The cores are hard to regression test - and as such are not.
  2. CASPER as an open source community is tied to a proprietary software (MATLAB & Simulink).
  3. We must use Vivado/Quartus to synth/imp our designs.

Over the years CASPER has made efforts to move away from Simulink and the latest effort has been my HDL work to have an HDL FFT and Polyphase Filterbank (see here. Having our cores in HDL allows us to regression test with VUnit (which you will see I have working finally). It also lets us explore other graphical frontends to wrap the cores in (though we have wrapped them in Simulink for backwards compatibility). Finally, it allows us to be vendor agnostic (not being tied to System Generator or DSP builder for the synth/imp of our DSP).

Eventually, our goal is for users to choose a graphical frontend from a host of offered ones, include our HDL library, create their design at a high level and deploy to a wide range of hardware by way of a synth/imp of their choice.

Sorry for the long message.

Unai Martinez-Corral
@umarcor
@talonmyburgh no need to be sorry. That's pretty exciting indeed! If you went through my history/profile in GitHub, you would find out that I joined the open source HDL/EDA community some years ago, with the horizon of having an open source alternative to the Mathworks-Siemens-Xilinx workflow. That's 100% the same use case as yours. My background is control systems (PID, MPC) and feedforward neural networks; i.e. DSP and linear algebra.
My motivation for searching an open source alternative was the lack of VHDL 2008 support, and the limited black-box approach of System Generator.
Five years ago, GHDL's 2008 support was not there yet, and HDL Verifier was not a thing. Therefore, the ecosystem is different today, but there is still place for an open source alternative. Particularly, HDL Verifier depends on UVM and SV's DPI-C, so it is not usable with open source or free tier licenses.
Let me gather some references that might be interesting for you:
Unai Martinez-Corral
@umarcor

I believe we can achieve that with VHDL/GHDL as well, and we can "freely" combine Verilog and/or VHDL modules with software blocks.

However, I know nothing about GNURadio and/or SDR.
Unai Martinez-Corral
@umarcor
Currently, I use VUnit as the build and execution tool, because I focus on simulation and co-simulation. I.e. having "digital twins" from py/m to VHDL software to VHDL hardware to synthesisable VHDL. Now, in order to extend that to synthesis and implementation execution, I'm helping @Paebbels elaborate edaa-org.github.io.
The diagram in https://umarcor.github.io/hwstudio/doc/#_structure shows all the pieces: VUnit, EDAA, CAPI, DOM, Sphinx, Constraints, GUI...
Talon
@talonmyburgh
Wow! We are very much aligned in our missions!
Yes I know Ross Donnachie, him and I have a small consulting firm together.

We've had meetings with GNURadio before to discuss making use of their GNURadio Companion for a Simulink Replacement.
As for MATLAB's FixPoint ToolBox, for my MSc I wrote a replacement (somewhat) in Python and am now converting it to Julia for speed. I used it for Fixpoint analysis FFT's on FPGA hardware (compiled through System Generator).

I'll inspect your GitHub closely, I'd looked at hwstudio before but didnt understand it.

Thanks a ton for all these references I'll look into them.

You should attend our next CASPER meeting/conference or you myself and Ross should meet sometime.

Adam Vrba
@civec

Hi all,
I experience a problems with use clause for locally declared packages.
architecture tb of tb_spi is .... package sb_rl_data is new bitvis_vip_scoreboard.generic_sb_pkg generic map (t_element => t_RL_ARRAY, element_match => slv_array_match, to_string_element => to_string); use sb_rl_data.all; shared variable SB_RL : sb_rl_data.t_generic_sb; ... begin
In this case the use clause do not starts with library name but with simple identifier. The problem is I'm getting the following warning :
WARNING - /tb/tb_data_switch.vhd: failed to find library 'sb_rl_data'
I expect this could also cause incorrect compilation order too.

Is this problem known or should I file a bug report?
Thanks for help

Adam Vrba
@civec
architecture tb of tb_spi is .... package sb_rl_data is new bitvis_vip_scoreboard.generic_sb_pkg generic map (t_element => t_RL_ARRAY, element_match => slv_array_match, to_string_element => to_string); use sb_rl_data.all; shared variable SB_RL : sb_rl_data.t_generic_sb; ... begin
GlenNicholls
@GlenNicholls
I'm having trouble reading that, can you put your code in a code-block? Use 3 backticks like so:
```
dasHorst99
@dasHorst99

Hi,

I am using vunit now for some weeks now and slowly get a hang of it. Nice little functions are included especially for the integer_array type. Very neet and usefull!
There is now one little task that I have solved but I am curious if some one could say me if there is a function for this or can maybe explain me how it can be done easier.

My task is that I want to read a bmp file. So I read the whole data by using the load_raw function. But I only want a chunk of that data for example the head. Also it must be considered that the bytes are ordered in little endian.

dasHorst99
@dasHorst99
impure function get_header_info(input_arr : integer_array_t; 
                                a   : natural;
                                b   : natural) return natural is

    variable output_value_vector : std_logic_vector(31 downto 0) := (others => '0');
    variable output_value_int    : natural := 0;
    variable output_arr          : integer_array_t := new_1d(4, 8, false);

begin    

    for x in a to b loop
        set(output_arr, x-a, get(input_arr, x));
    end loop;                        

    output_value_vector := std_logic_vector(to_unsigned(get(output_arr, 3), 8)) &
                    std_logic_vector(to_unsigned(get(output_arr, 2), 8)) &
                    std_logic_vector(to_unsigned(get(output_arr, 1), 8)) &
                    std_logic_vector(to_unsigned(get(output_arr, 0), 8));

    output_value_int := to_integer(unsigned(output_value_vector));

    return output_value_int;

end function;

This is not the best code, so maybe there is a better or more convinient way to do this?

Best regards

Oh, I almost forgot to mention something important.
I want these chunks intepreted as whole number. That's why I put the 32 bit vector together from 8 bit pieces.
Patrick Lehmann
@Paebbels
@dasHorst99 Type integer can't hold your data, as it is a signed data type. Thus you have only 0 → 2**31 - 1 as unsigned values.
dasHorst99
@dasHorst99
@Paebbels Yes, you are right. I've tried something to take this fact into accout but till now I couldn't find a proper way to do it.
Patrick Lehmann
@Paebbels
why do you need the RGB color from a BMP file as integer. It's a record of 3 color values not a single value.
Richard Head
@trickyhead_gitlab
RGB in bitmap are only 8 bits per channel. If you are using windows BMP format then the final 8 bits are an alpha channel
But "standard" bitmap is only RGB with no alpha
Patrick Lehmann
@Paebbels
function swap(value : std_logic_vector; size : positive := 8) return std_logic_vector is
  constant segments : natural := value'length / size;
  variable result : std_logic_vector(value'length - 1 downto 0);
begin
  for i in 0 to segments - 1 loop
    result((segments - i) * size - 1 downto (segments - i - 1) * size) := value((i + 1) * size - 1 downto i * size);
  end loop;
  return result;
end function;
dasHorst99
@dasHorst99
@Paebbels This is to read the information of the image header, like for example te header size or the image data offset, which I need to read the image data.
Richard Head
@trickyhead_gitlab
From experience, you can simply ignore alpha - I dont think many tools actually use it
@dasHorst99 why not simply read into arrays of slvs via a char?
using something like this:
procedure read_bytes( file     f :     data_file_t;
                          variable s : out std_logic_vector ) is
        variable c_buf   : character;
    begin
        for i in 0 to (s'length/8) -1 loop
            read(f, c_buf);

            s( (8*i) +7 downto i*8 ) := char_to_slv(c_buf);
        end loop;
    end procedure read_bytes;
you can strip a bitmap header like this:
procedure strip_header( file bmp    : data_file_t;
                                 do_abs : boolean := true;
                                 path   : string  := "";    --only used for reports declaring file is invalid

                                 bpp    : out natural       --only valid values are 8 (greyscale), 24 (RGB) and 32(RGBA)
                           ) is


        variable ret_dims   : image_dimensions_t;

        variable c_buf      : character; --this is the data buffer for reading from the file
        variable slv_buf    : std_logic_vector(31 downto 0);
        variable is_V4      : boolean := false;
        variable bpp_i      : integer;
    begin

        --we take in the first 2 bytes to make sure this is actually a BMP
        read_bytes(bmp, slv_buf(15 downto 0));

        assert slv_buf(15 downto 0) = x"4D42"      --First two bytes should be BM in Ascii
          report "image_file_io_pkg.strip_header : " & path & " is not a valid BMP file."
            severity failure;


        ----------------------------------------------------------------------------------------------
        --throw away the next 12 bytes
        --This is just the filesize, followed by 4 reserved bytes, then data offset
        -----------------------------------------------------------------------------------------------
        for i in 1 to 12 loop
          read(bmp, c_buf);
        end loop;

        -----------------------------------------------------------------------------------------------
        --Next 4 bytes is the header size. Check that it is a supported type, and we can bin the rest
        --if its V4 type.
        -----------------------------------------------------------------------------------------------
        read_bytes(bmp, slv_buf);
        if    slv_buf(7 downto 0) = x"6C" then is_V4 := true;
        elsif slv_buf(7 downto 0) = x"28" then null;          --catch V3 header
        else
            report "image_file_io_pkg.strip_header : " & path & " is not a supported bitmap format."
                  severity failure;
        end if;


        ---------------------------------------
        --Next 32 bit word is the width, followed by height
        ---------------------------------------
        read_bytes(bmp, slv_buf);
        ret_dims.width  := to_integer( signed(slv_buf));

        read_bytes(bmp, slv_buf);
        ret_dims.height := to_integer( signed(slv_buf));

        --if do_abs then
        --    dims.width  := abs ret_dims.width ;
        --    dims.height := abs ret_dims.height;
        --
        --else
        --    dims.width  :=     ret_dims.width ;
        --    dims.height :=     ret_dims.height;
        --end if;

        --report "Width is " & to_string(ret_dims.width) & " height is " & to_string(ret_dims.height) severity note;

        ---------------------------------------
        --Dump the colour planes
        ---------------------------------------
        for i in 1 to 2 loop read(bmp, c_buf); end loop;

        ---------------------------------------
        --Check the bits per pixel
        ---------------------------------------
        slv_buf(31 downto 16)   := x"0000";    --If height was -ve, we would be in trouble if this didnt happen!
        read_bytes(bmp, slv_buf(15 downto 0));

        bpp_i       := to_integer(unsigned(slv_buf));
        bpp         := bpp_i;


        ----------------------------------------------------------------------------------------
        --Dump the next 6 header fields
        --
        --Compression - Not read but if BPP=32 then it is assumed BI_BITFIELDS are set.
        --              See write_header procedure for assumed position of the RGBA bitfields
        --data size   - taken from height and width
        --horizontal physical resolution
        --vertical physical resolution
        --n colours in colour palette
        --all colours are always important
        -----------------------------------------------------------------------------------------
for i in 1 to 6 loop
            read_bytes(bmp, slv_buf);
        end loop;

        ----------------------------------
        --Dump the V4 fields
        ----------------------------------
        if is_v4 then
            for i in 1 to 17 loop
                read_bytes(bmp, slv_buf);
            end loop;
        end if;

        ------------------------------------------------------------------
        --If the bpp is set to 8, then throw away the colour table.
        --It is assumed to be greyscale and binary data read directly
        ------------------------------------------------------------------
        if bpp_i = 8 then
            for i in 0 to 255 loop
                read_bytes(bmp, slv_buf);
            end loop;
        end if;

    end procedure strip_header;
dasHorst99
@dasHorst99

@trickyhead_gitlab

RGB in bitmap are only 8 bits per channel. If you are using windows BMP format then the final 8 bits are an alpha channel

This is then a 24 bit bmp, right?
What do you mean with the last bits? The last bits of the image data?

Richard Head
@trickyhead_gitlab
In bitmap, you can have any of 8, 24 or 32 bits per pixel
8 bits uses a colour table of 24 bit RGB values to specify a map of the 8 bits to a 24bit RGB value. Usually this is used for greyscale images.
24 bits is purely RGB, with 8 bits for each channel. There is no colour table.
32 bits is RGBA, 8 bits per channel. This adds an alpha channel
dasHorst99
@dasHorst99

@trickyhead_gitlab Thank you for your information and your code! I will inspect and try to understand it.

@trickyhead_gitlab

why not simply read into arrays of slvs via a char?

Simply because I don't know what slvs is. ;) I have to look it up.

Richard Head
@trickyhead_gitlab
std_logic_vectors - one of the most used types in VHDL..
dasHorst99
@dasHorst99

Ha, I know std_logic_vectors. I am not so dump after all. ;) Now I am checking slvs was the abbreviation.

My first attempt was exactly this approach, but my code was big and not nice. Now with the vunit functions it is a lot smaller and not so complicated. Therefore I accept the integer conversion with the integer_array.

Lars Asplund
@LarsAsplund
@dasHorst99 I haven't looked into it but this sounds like a case where I would consider using the vast ecosystem of Python to convert the BMP to CSV. Put that code in a preconfig function to your test(s) and load the CSV from your VHDL.