Arrays - detect signal changes and simulate in Modelsim

[Altera_Forum]

I have two problems with a 1-d array I'm using. The array's cells are 64 bit vectors.  

Declaration:  package my_pack is type commands_array is array (natural range <>) of std_logic_vector(63 downto 0); end package;  The same type of array is an output of one module and an input of another. In one of the modules the array port is this: packets_in : in commands_array(0 to 17);  1. I'm also trying to simulate this using Modelsim, but am getting the following error: too many indices (2) for array type work.my_pack.commands_array (dimensionality 1).  This is the code line with trouble: packets_in : IN commands_array(0 TO 17 , 63 DOWNTO 0);  2. I'm trying to use SignalTap to view the arrays but they are always 0. Even when my code worked (though not in the way I wanted) I saw that my outputs, the array's cells, are correct, so the problem is not with the arrays. Is there anything I can do about that?  Thank you!  edit: I deleted the first question because I succeeded (almost). I am more interested in the other two. I still have some problems in my design and getting to simulate it would help a lot.

[Altera_Forum]

Please see edit, I still have problems simulating the design. Thank you!

[Altera_Forum]

1. Commands_array, is a 1D array, but you're trying to declare packets_in as a 2D array. because the commands_array type (usual convention is to pre/post pend type names with _t or _type to avoid confusion with signals/variables etc) already has 64 bit slv's declared, there is no need to declare the size of them. 

 In vhdl 2008, it is legal to a declare array types of an unconstrained array type, and then declare the length when you create the signal/variable. Something like:   type commands_array_t is array (natural range <>) of std_logic_vector; ... packets_in : in commads_array_t(0 to 17)(63 downto 0);   this should not be confused with 2d arrays, which use the syntax you're trying. But I would avoid 2d arrays here, as they are not sliceable.   type commands_array_t is array (natural range <>, natural range <>) of std_logic; -- really not fun to use .... packets_in : in commands_array_t(0 to 17, 63 downto 0);    2. Is the signal marked as red? that means signatap could not find the net in the final design. Otherwise if it's black/blue and always zero - then it really is zero.

[Altera_Forum]

Hey Tricky, once again, thanks for your help. 

 1. To be honest, this error is from an HDL file created by Quartus from the BDF file that is my top entity (something I feel like I should have mentioned). I am very surprised that Quartus did this, and that my design actually compiles (and works).   I deleted the "63 downto 0" completely (since the array is declared as an array of vectors with 64 bits, so it seems unnecessary) and it seems to compile, and simulate. Haven't checked on the arrays yet, if I have a problem I will ask.  2. The arrays (I took both input and output on purpose) are not red, they're black. Like I said, it's impossible that they are zero, because there is a signal that receives a small part of the cell's value (8 bits out of the 64, each one at a time), and I see from this signal that the arrays are okay. They are also not initialized automatically, and I checked them at various points in time, and they always seem to be zero, so that is weird.  A question though, I saw that if I have a signal that is defined outside of a process I cannot monitor it in SignalTap. Why is that?

[Altera_Forum]

1. You've probably found the hiddeous (imho) std_logic_2d_t decleared in an altera package that is used when you define a 2d array in a bdf file and convert it to VHDL. Please avoid at all costs. 

Be aware that quartus is not properly standards compliant and will let you get away with some things that modelsim will complain about. (this is probably down to the fact that verilog works and the underlying logic works so why let a few VHDL rules get in the way!)  2. I still stand by your logic outputting 0. You can monitor ANY signal in signaltap - where did you read such lies?

[Altera_Forum]

1. Well, I defined the array as a 1-d array of vectors in a package (like I've shown in the first post) and defined the problematic ports as 1-d arrays as well, inside the VHDL files themselves (never heard of defining an array in a BDF file, so I'm not sure I understand you). 

Unfortunately I can't really avoid that, because I make an HDL file from a BDF for the purpose of simulating in Modelsim. Is there something I can do so that Quartus will not convert the arrays to 2-d?  2. About the SignalTap, I haven't read it anywhere :) - I'm speaking from experience. I declared a signal, assigned it to be something in the architecture and not a process (a < '1' when x = '1' else '0', for example, where a is the signal I want to monitor) and wasn't able to find it in SignalTap. I put it in a process and next thing I know, I see it. I tried to do that again to make sure I'm not mistaken, and it happened again.  I should mention I'm working with Quartus 13.0 sp1, because I need support for the DE2. Maybe it's a bug? I honestly thought maybe it's because I don't understand logic analyzers. Also, when searching for signals/pins, I always use design entry (all names) as my filter.  I understand why you would think my logic is outputting 0 but I can assure you it's not. The 8-bit vectors eventually go to a UART module I made that converts the data to serial, and from there it's sent to servos. Not only do I see in SignalTap that my logic's output is fine (like the serial output), but the servos themselves are working perfectly. I can prove it to you if you wish by attaching a screenshot :)

[Altera_Forum]

1. in the BDF, a 2d array will come from something like: packets_in[0..17][63..0]. Your VHDL commands_array type will look like a 2d array in quartus in the BDF, and will generate it as such, as you have seen. To avoid this - dont use BDF (its all a throwback to AHDL, and none of us need that headache anymore). Do yourself a favour and make your design more portable and version control friendly by removing all use of BDF. 

 2. This is probably because the net has been renamed or merged. It's usually best to search for post-synthesis nets as these will be the ones that really exist. For example, it tends to keep entity output names, so if you connected my_block_out to some_other_block_in, the latter name will probably be removed. If you add the latter in signaltap, my experience is that it will show up as red in the final compiled version as a net that no longer exists.  There are way around this. There are some attributes to try and preserve nets and zero fan out registers (debug logic you only want connected to signaltap for example).   These are noprune for nets  http://quartushelp.altera.com/14.1/mergedprojects/hdl/vhdl/vhdl_file_dir_noprune.htm   and preserve for registers with no fanout http://quartushelp.altera.com/14.0/mergedprojects/hdl/vhdl/vhdl_file_dir_preserve.htm

[Altera_Forum]

1. I love using BDF files because the only alternative that I know is implementing your entire design by code. IMHO it's much easier to see your design visually, how everything connects, all the pins, all the inner signals (nets), than seeing it by code. If I had done it by code (components) I would always wonder if I made some mistake. 

Is there some other alternative that I may not know about? One where you can actually see the blocks and nets, like in a BDF file?  2. Thanks for the info! I did not know about these attributes, or even fan-out (shame on me), and by experimenting for a while I saw that a signal can really be unselectable or become red when it has no fan-out. You saved me a lot of confusion in the future :)

[Altera_Forum]

1. No. The only portable and version control friendly method is with HDL (VHDL or (System)Verilog). BDF files only work in Quartus, so if you need to port your design to Xilinx or some other tool, you'll have to convert it to VHDL anyway. Mentor do have a tool called HDL designer that tries to keep as much HDL as it can, but its not free and its very much a love it or hate it tool (most engineers I know hate it, because again, its another tool you'll need a licence for). At the end of the day, HDL can be edited with windows notepad. BDF/other graphical tools cant. 

If you insist on using .bdf files, you wont find yourself employable.