Technology Blogs

Thank you for the compliment.

> How did you create these pictures? is there a tool for that?

Just Microsoft PowerPoint, other drawing packages are available…

Hey!
Thank you for nice article.
How did you create these pictures? is there a tool for that?

Vivado IP is the next level of abstraction up. You would need to generate the FIR filter and then figure out which files you needed to include in your broader compile script. For example:

PLL:

• pll\pll_sim_netlist.vhdl

AXI IP:

• axis_broadcaster\gen\axis_broadcaster_sim_netlist.vhdl
• axis_combiner\gen\axis_combiner_sim_netlist.vhdl
• axis_register_slice\gen\axis_register_slice_sim_netlist.vhdl

DFX Controller: You will need something more elaborate like https://github.com/philipabbey/fpga/blob/main/VHDL/DFX_PS/modelsim_compile.cmd

There’s no simple answer here, you have to do the hard work to figure it out. Good Luck!

Hey!

how can I compile xilinx IP like for example FIR compiler with this?

Thank you for taking the time to post your appreciation. I think you have spotted a mistake and I need to re-test with your correction.

The AMD/Xilinx question states “This question is closed", so I can’t add anything new to it. Perhaps one day I will get a reddit account and post there, but feel free to make the link yourself.

Best wishes,

Philip

Hi,

I want to thank you for this post, I don’t have deep knowledge of TCL and without this post I don’t think I would have been able to use the Vivado libraries in QuestaSim.

I think this post is much more useful than the two posts you quote from the AMD forum and Reddit so I encourage you to write an entry in that Reddit post with the link to this website, as it appears much higher than this website in Google searches.

Just a comment: when you compile the XPM library on lines 142-145 I think the correct path to the FIFOs package is

"%xpm%\xpm_fifo\hdl\xpm_fifo.sv" ^

instead of

"%xpm%\xpm_fifo\simulation\xpm_fifo_tb.sv" ^

Or at least that’s how it worked for me.

Regards,

Pablo

Xilinx would appear to have already written an IP core for their FPGAs according to this document: LDPC Encoder Decoder v1.0 Product Brief (PB052)

No! I’m afraid I had to look Low-density parity-check code up on Wikipedia. I will have to consider that, thanks for the pointer. I did find the 01 signal sampling was superior to these methods. BTW I am currently double checking my work here as it happens.

Hi Erik,

The line of code you point to is a pure signal (wire) assignment outside a clocked process and hence there’s no register on that line. The ready signal takes the output from the register on line 68. It then inverts it before it leaves the component. Strictly speaking that’s not purely registered, but for most cases it is good enough. If you want a fully registered solution take a look at the AXI Register Slice from Xilinx.

I’ve referred to the ITDev blog post many times when working with AXI-S. I use their non-registered solution all the time as it is so simple. I’m glad to have been of use, but I can’t take credit for the original article.

Philip

Hi Philip,

Let me thank you for such a wonderful post. I’m starting to battle with managing upstream and downstream axi connections and I felt like missing something, and this post has just nailed it.

Just a quick question: In the pipelined solution, you say you’re registering the ready signal. Does that occur in line 82 where us_ready <= not expansion_valid_reg; , because expansion_valid_reg is assigned synchronously?

Thank you!

Thank you for your kind words.

Philip

I’ve just discovered this blog post and I’d like to thank you for it.
This post, just like the whole blog is just great!

Thank you, I think I have found your replacement and now updated the link above.

Hi Philip, thanks for this nice write-up!

In the Notes on Clock Uncertainty section, the link to the Xilinx Forum article Timing summary understanding is broken.

The target article can be found via the following URL:
https://support.xilinx.com/s/question/0D52E00006hpKmUSAU/timing-summary-understanding?language=en_US

Hoping that Xilinx will implement HTTP redirects (code 301) next time they migrate their community forums.

Regards
Matthieu

It is also worth noting that you can update a VHDL signal from TCL using the force command:
force -deposit <signal_name> <value></value></signal_name>

This means that bidirectional communication between TCL and VHDL is possible.