Always interesting to learn a new tool. We'd picked up on UVVM (Universal VHDL Verification Methodology) library from some Aldec online seminars and were impressed with their breadth of library functions. I took it upon myself to use a block I've used a few places, an asynchronous FIFO, thinking it would be a great object to test as it was working well. I had designed it to have an Avalon Streaming style interface for in and out.

Well I got it verified but along the way discovered that the Avalon Streaming self-imposed requirement wasn't verifiable, and it involved going down a rabbithole on simulation/synthesis behavior mismatch, inferring block RAM with first word fall through in VHDL and Verilog, and more. Definitely an eye-opening effort!

I have it spiffed up quite nicely, now just have to check places where it was used -- those places I probably designed around my own flaws. Good library!!

#vhdl #verilog #fpga #uvvm #aldec #avalon

Oh, it's a thing of beauty. The #gnuradio CW was maxed at 1.0 and that was overranging in my receiver. Also adding the gaussian rise/fall times helped out a lot (greasing the frequency skids).

The result: the output of the polar coordinate receiver showing a beautiful magnitude response in #Aldec #rivierapro with GNU Radio acting as stimulus. The amount of code it took to bang this out in GNU Radio (python) was far less clunky than trying to piece it together in HDL languages and should be more reusable.

#fpga #sdr #simulation #verification

Starting a first major #gnuradio #riviera co-simulation testbench. #Aldec has been very helpful. Established that in my own testing (not just the example project) I could see the data flow across, now I am refactoring that, and then adding in a complex receiver. Neat stuff.

Sweet! Finally got the #gnuradio and #aldec #riviera-pro linkage to work. Still don't have a handle on complete testbench flow control (it crashes after about 40 us with a Gnu Radio library error) but even this is pretty neat. I could either bolt on our receiver design (already verified but would be interesting to see the result with this stimulus), or improve the stimulus side, make it more parameterized so I can tweak it towards the tolerance limits.

But it freakin' works and that is really nice.

#fpga #sdr

Also while #WSL has been working quite well for all this, there are some quirks to be sure. Did you know it generates a brand new MAC address at every initialization of the kernel? I didn't until I tried to run a license server on it. (And no, absolutely none of the WSL help for managing this worked.) Also, the #Qt library #Aldec used for Riviera occasionally gets a little freaked out and I get a window whose relationship with the mouse pointer is ... wrong. This means it's near impossible to click anything in the GUI. Finally managed to get it shrunk down to a size and I'll just remember not to use the maximize button and instead go full screen.

I'm sure there'd be weird quirks if I were running native Linux too, these are just the ones I've found in WSL.

#Windows #Linux

Getting closer to a real #gnuradio and #vhdl co-simulation. Required a more elaborate simulation invocation than I usually use, and now just getting a (hopefully) final error about SCEMI not finding the right ports.

So very close.

#sdr #fpga #aldec #riviera

Successfully got the #gnuradio and #aldec #riviera-pro interface working for their sample demonstration. Now have to tear it apart and try to figure out the best way to get it to work with an actual project that delivers something useful!

#fpga #vhdl #sdr

So very close to getting #gnuradio and #aldec #riviera-pro to work together. Now it's just a matter of libraries I think. Seems like maybe they wrote things for a different version of GNU Radio. Of course this is just the EXAMPLE. Getting it to work with my own material is probably another question entirely.

Aha! With #Aldec help, I've got Riviera-PRO running in Linux (Windows + WSL). I've got #gnuradio doing a Mode A transmission. I just need the final piece to connect the two and then I've got full cosimulation!

#sdr #fpga #vhdl

Well appears as if there's no concept of time in #gnuradio. Everything is sample based. It's understandable but means the first helper module I think I will need to write is a sample counter though to provide other modules with a concept of time.

#fpga #aldec #vhdl #riviera-pro

@Tathar Well, for avionics test, I do signal receipt and correlation and demodulation, then the other side modulation and transmission in #VHDL. However that's not what's making me walk through gnuradio. Apparently #Aldec has a block that lets you use #gnuradio in co-simulation with #Riviera-PRO. If I have an easier to work with signal generation or signal analysis tool, it would aid verification.

I've written signal toolbox stuff in VHDL for simulation, but I'll be honest, it's a pain in the ass to work with: tedious to construct and a pain in the ass to modify (depending on what you want.). There's a possibility gnuradio is easier (though also a possibility it is not. I've not yet got through a tutorial that actually gave me a sense of how the tool deals with time. I think it probably doesn't which means if I need a particular timing I will be sample counting and it'll make it anchored to sample rate when it'd just be nicer to wait X microseconds and then modulate.)

Progressing further through the #gnuradio tutorials. I'm not sure I"m yet to the point of knowing how to apply time based modulation to the signals, but possibly getting closer.

#sdr #fpga #aldec #riviera #vhdl

Playing around with GNU Radio, a software suite I had no idea existed until the other day. Apparently there's also (when I get more proficient with it) a way to pipe the output of this into Riviera-PRO for FPGA simulation. I have LONG wanted a better signal generation sandbox for verification and this could potentially be very neat. Just a lot of baby steps to learn it, it's a beast of a software and I need to be able to write modulation schemes for SIF, Mode S, et al

#sdr #vhdl #fpga #avionics #aldec #simulation