@dpaul24 You're using
allow_empty=True. Is that because it didn't find any testbenches? Note that the sim option only applies to testbenches added before the sim option was set.
Well I did not give it much thought, I just think it would be safe to use the TRUE setting. btw - All my TBs are loaded I use vu_prj.set_sim_option("disable_ieee_warnings", True, allow_empty=True)
constant master_axi_stream : axi_stream_master_t := new_axi_stream_master(
data_length => data_width
user_length => 1
user_lengthand all other parameters.
I have another question. This time about the pop function from AXI stream.
I want to push and pop the tuser flag on axi stream. Push works fine, but I can't pop it.
It gives me the following error, but I don' t know why.
(vcom-1600) No feasible entries for subprogram "pop_axi_stream".
I configured the master and slave the same way:
constant master_axi_stream_bus : axi_stream_master_t := new_axi_stream_master( data_length => data_width, user_length => tuser_width ); constant slave_axi_stream_bus : axi_stream_slave_t := new_axi_stream_slave( data_length => data_width, user_length => tuser_width );
variable user : std_logic_vector(tuser_width-1 downto 0);
And my pop function looks like this:
pop_axi_stream(net, slave_axi_stream_bus, tdata => received_data, tlast => last, tuser => user);
Without the tuser all works fine.
Does anyone perhaps have a suggestion?
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:
Is this possible? I've not seen any way to remove tb configurations.
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:
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.
I believe we can achieve that with VHDL/GHDL as well, and we can "freely" combine Verilog and/or VHDL modules with software blocks.