cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
raspecht
Visitor
Visitor
5,925 Views
Registered: ‎01-24-2012

Arrays & Records in Port Declarations

In all my previous design work, I've never seen this as an issue.  However, in chapter 5 of the documentation is says "not to declare arrays in ports" for the following reasons

 

  • Incompatibility with Verilog
  • Inability to Store and Re-Create Original Array Declaration
  • Mis-Correlation of Software Pin Names

 

I understand the issue "in general", but how big of a deal is it in a Xilinx tool flow.

 

Put it simply...in most of my designs, utilizing arrays/records reduces the amount of lines of code by usually 70% (e.g. too many lines of code are connectivity "fluff"). 

 

Note: I don't use arrays in at the top level for items I will synthesize.

0 Kudos
4 Replies
gszakacs
Professor
Professor
5,911 Views
Registered: ‎08-14-2007

So

 

1) You're using VHDL, and have no reason to translate code into Verilog, or use

arrays or structures in VHDL entities that could be instantiated within a Verilog

module.

 

2) You have a common definition of the array that is pasted into each entity that

uses this interface.

 

3) You aren't worried about software renaming of pins, because after all when you

look at the post-synthesis netlist, who can figure it out anyway?

 

If I'm on the right track, and you don't get any synthesis errors, then it's not a big

deal at all.  Personally if I could do this in Verilog I would.  I find it much better

than declaring a 37-bit bus to house 32 data bits and 5 other random bits and

requiring every module to have the magic decoder ring to keep track of the

meaning of those extra 5 bits.

 

Don't read too much into the style recommendations in the documentation.  Do what

works well for you.

 

-- Gabor

-- Gabor
bassman59
Historian
Historian
5,898 Views
Registered: ‎02-25-2008


@raspecht wrote:

In all my previous design work, I've never seen this as an issue.  However, in chapter 5 of the documentation is says "not to declare arrays in ports" for the following reasons

 

  • Incompatibility with Verilog
  • Inability to Store and Re-Create Original Array Declaration
  • Mis-Correlation of Software Pin Names

 

I understand the issue "in general", but how big of a deal is it in a Xilinx tool flow.

 

Put it simply...in most of my designs, utilizing arrays/records reduces the amount of lines of code by usually 70% (e.g. too many lines of code are connectivity "fluff"). 

 

Note: I don't use arrays in at the top level for items I will synthesize.


I think the documentation's concerns are overwrought.

Code in a way that makes sense to you, and to whomever has to read your code later. 

And you're right, as long as the top level avoids complex arrays, then the tools, mainly the UCF trying to match net names to pin names, will be happy.

 

There are all sorts of admonishments about not using non-std_logic/std_logic_vector in port lists. Ignore them, especially if you aren't doing anything mixed-language. I use unsigned or signed or ranged integers all the time.

----------------------------Yes, I do this for a living.
0 Kudos
raspecht
Visitor
Visitor
5,893 Views
Registered: ‎01-24-2012

1.  Correct.  I'm in the Midwest...so VHDL is norm here.   While I’m okay with Verilog...I spend more of my time dealing with system architecture than trying to get more efficiency out of a function.  I've honestly found out that I save more resources by planning the system  better than cobbling "efficient" blocks together.

 

 2.  Correct.  I extensively use packages to store types, constants, and records.   This means, as long as I declare the library in the VHD file, every is on the same page.  For example, out of my memory interface I have ~200 registers for 7 or 8 functions.  I can put all those signals into single record.   Therefore I can declare that record as an input to every single block regardless of type.  If they don’t use the signal…it just gets optimized out.  Therefore 200 signals become 1 and the top level never changes even if I add 2000 more signals.

 

 3. Correct. While SW renaming of pins can be annoying, I try as hard as I can to make that a "non-issue" by architecting around "global constraints" as much as possible.  Years of level A&B designs forced synchronous design into my brain something fierce and I can't get it out.  With new FPGA's drawing on that (the GSR, etc)...it seems that method is becoming more desired every day.   Also, when it comes to timing, if you have a violation….I find it more often to be systemic of poorly written code for that function in general vs having to tighten the screws on a single net.

 

Who knows, maybe someday I’ll be put on a telecom design where they need to squeeze every LUT and MHz they can out of the design. But until that day, I’ll keep on doing the job of 3.

 

Thanks for your comments and help.

 

0 Kudos
rcingham
Teacher
Teacher
5,883 Views
Registered: ‎09-09-2010

The current version of XST is a bit more VHDL-savvy than synthesizers used to be, and so the port restriction is probably overly cautios, especially in terms of records. If you aren't going to migrate your code to different vendor tools, carry on as you have been doing.

Hoever, I wouldn't use signed and unsigned types in ports unless I was sure that everybody was only using the numeric_std package, and not any of the old Synopsys packages - like some (most?) of the CoreGen output!

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos