Parallel VHDL

[Altera_Forum]

Hi all,  

Q1. I cam across this nice piece of code for a parallel barrel shifter from a book. I could barely understand it at first so I am wondering what level of expertise is this code at. Are there any particular tools that can convert diagrams or some sort of instructions into compact and effective code like this one or is it just experience that gets one there? If the latter, what is the methodology to write code like this for other particular situations, like a multiplier for example?   library ieee; use ieee.std_logic_1164.all; entity barrel is port( in0 : in std_logic_vector(15 downto 0); s : in std_logic_vector(3 downto 0); y : out std_logic_vector(15 downto 0)); end barrel; architecture rtl of barrel is constant n : integer := 16; constant m : integer := 4; type arytype is array(m downto 0) of std_logic_vector (n-1 downto 0); signal intsig, left, pass : arytype; signal zeros : std_logic_vector(n -1 downto 0); begin zeros <= (others => '0'); intsig(0) <= in0; muxgen : for j in 1 to m generate pass(j) <= intsig(j-1); left(j) <= intsig(j-1)(n-2**(j-1)-1 downto 0) & zeros(2**(j-1)-1 downto 0); intsig(j)<= pass(j) when s(j-1) = '0' else left(j); end generate; y <= intsig(m); end rtl;  Q2. I am designing a small cpu with vhdl. I am simulating the whole project in Modelsim and since I have the instructions loaded onto the memory wired to the cpu, i don't require a testbench necessarily. I am struggling though trying to figure out if all is working as should be as there are couple of signals and things going on. I added signals to a list window but wasn't of much use as I cannot open it with excel. Do you guys use any techniques to automate testing other than a testbench? Something that verifies each step?  Looking forward for your ideas... 

[Altera_Forum]

1. Is there anything you're particularly struggling with? This is fairly standard VHDL, but I feel its probably been written this way to be as compact and obfuscated as possible. There are no comments explaining anything, m is a constant in the file with no dependence on generics. There is also some code I dont like - zeros is a signal and not a constant! 

If you want to see a diagram, Quartus can provide RTL diagrams and technology mapped (ie. primitives) version via tools -> netlist viewers  2. Unless you're going to do all testing and debugging on chip (very slow, very time consuming) you are going to need a testbench. At a very basic level, the testbench needs to drive the clock and reset, then you need to add in any external stimulus to verify design operation.  Do you have any specific questions?

[Altera_Forum]

Thanks Tricky.  

 1. I use RTL viewer a lot; to verify the code I write reflects the logic I have in mind. I struggle with trying to uncompact code like this so to figure out what logic it will infer and how it actually works and also how to write compact code like this for other projects. When you say standard VHDL, how do you exactly mean? I'm pretty sure someone who just learned how to blink an led won't write this kinda code next. There are many other barrel shifting examples online yet this one is short in code and uses just enough logic, which is great.  So if it's as you say, fairly standard, can you point me to resource where I can learn how to make code like this please?  2. To give a simple example, imagine an ALU code (with VHDL) and a testbench for it to input numbers every so period. Is there a way to verify the output is correct other then the tesbench and asserting warnings? Like a do script straight in modelsim for example, or comparing values from a list table automatically in excel for example?

[Altera_Forum]

1. When I say farily standard, its just code similar to that Ive seen over the years. Beginners probably wont understand it - but any VHDL engineer with a year or twos experience should be able to work it out. 

2. You can verify the results in the testbench. At a basic level you've probably got a set of stimulus, a set of expected results and you can just check them in the testbench. Then you could move on to writing a model of the ALU that runs in the testbench alongside the DUT, and then provide random stimulus so make the testbench self checking. As you move up in skill with testbenches you can model all kinds of things to packets to bus transactions etc, and sequence them all to cover as many situations as practical.

[Altera_Forum]

--- Quote Start ---  Q1. I cam across this nice piece of code for a parallel barrel shifter from a book. I could barely understand it at first so I am wondering what level of expertise is this code at. Are there any particular tools that can convert diagrams or some sort of instructions into compact and effective code like this one or is it just experience that gets one there? If the latter, what is the methodology to write code like this for other particular situations, like a multiplier for example?  --- Quote End ---    Is there some reason you don't want to use built in barrel shifters? I think Altera calles it LPM_CLSHIFT and VHDL has shift functions as well. I doubt if you can make one more efficiently than they can. If you are trying to understand barrel shifters, this code may not be a good example. Also, there are many options (left vs right, logical vs rotate etc ) that is does not have.    --- Quote Start ---  Q2. I am designing a small cpu with vhdl. I am simulating the whole project in Modelsim and since I have the instructions loaded onto the memory wired to the cpu, i don't require a testbench necessarily. I am struggling though trying to figure out if all is working as should be as there are couple of signals and things going on. I added signals to a list window but wasn't of much use as I cannot open it with excel. Do you guys use any techniques to automate testing other than a testbench? Something that verifies each step?  --- Quote End ---    Why don't you want to use a testbench? I believe you can export the waveform to csv file that you could in fact open in Excel, but why? A testbench can read stimulus and result vectors from files and verify results. But it can do all sorts of other things as well. Will your CPU have an adder? You could easily write code to verify that instead of massive stimulus files.

[Altera_Forum]

Thanks corestar and tricky. I forgot about the LPM blocks. I shall definately use the ready made ones. I avoid testbenches as I am not very good with. But I'll put effort. I understand the value of testbenches but they feel abstract at first and never managed to work around the problem. Thanks for the support though.

[Altera_Forum]

--- Quote Start ---  Thanks corestar and tricky. I forgot about the LPM blocks. I shall definately use the ready made ones. I avoid testbenches as I am not very good with. But I'll put effort. I understand the value of testbenches but they feel abstract at first and never managed to work around the problem. Thanks for the support though.  --- Quote End ---    Remember, we can help with testbench issues as well if you get stuck...

[Altera_Forum]

--- Quote Start ---  Thanks corestar and tricky. I forgot about the LPM blocks. I shall definately use the ready made ones. I avoid testbenches as I am not very good with. But I'll put effort. I understand the value of testbenches but they feel abstract at first and never managed to work around the problem. Thanks for the support though.  --- Quote End ---    You've actually gotten pretty far; you have Modelsim running and are applying stimulus and getting results. You've sort of done half a test bench. You just need the last step of verifying the results. I know it's always tempting to quickly get things running using tools you know (eg Excel), but learning how to verify results in a test bench is not too far beyond what you are already doing.   Not to add another complication, but VHDL is, in my opinion, a horrible simulation language. When it comes to synthesis, VHDL and Verilog are a toss up as to which is the least stupid. For simulation, SystemVerilog is probably far superior to VHDL. Just printing out values is difficult in VHDL. Probably best to stick to VHDL simulation for VHDL code for now though. Tricky is far more knowledgeable in such areas and may have a different opinion.

[Altera_Forum]

--- Quote Start ---   Not to add another complication, but VHDL is, in my opinion, a horrible simulation language. When it comes to synthesis, VHDL and Verilog are a toss up as to which is the least stupid. For simulation, SystemVerilog is probably far superior to VHDL. Just printing out values is difficult in VHDL. Probably best to stick to VHDL simulation for VHDL code for now though. Tricky is far more knowledgeable in such areas and may have a different opinion.  --- Quote End ---    VHDL can do a hell of a lot, and life is made easier with VHDL 2008 (all standard types have to_string, to_ostring and to_hstring functions, for example). Most stuff you can do with SV you can do with VHDL. Where VHDL falls down compared to SV is re-use  I will admit that it can be a chore for some things in VHDL - if you write stuff away in packages it makes life easier and re-usable.  I am now someone who now writes testbenches in SV because of the re-use and stuff you get for free - but SV can get very confusing very quickly for a VHDL only engineer.  10 years writing testbenches in VHDL now has me libraries for reading/writing bitmap files at either 8 or 10 bit per pixel, plenty of stimulus generation, and I even built a generic linked list (ie. it will work with any type).  I highly recommend learning testbenches in VHDL. It was my knowledge of testbenching that helped me learn SV. It is not an easy thing to pick up if you are not already skilled in writing tests.