Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Conditional module ports

Reply
Thread Tools

Conditional module ports

 
 
Mike Treseler
Guest
Posts: n/a
 
      10-30-2007
M. Hamed wrote:

> I think I will go with the two entities (two architectures?)
> approach. It makes it easier to understand and maintain. I agree the
> other two options are ugly however I don't totally agree they're
> better than a preprocessor. I think a built-in VHDL preprocessor that
> is recognized by the synthesis tool would have made my life easier.
> After all this is a medium size VHDL project after which my group
> management decided to switch to Verilog. It doesn't really pay to
> strictly adhere to VHDL standard and conceptions when getting the job
> done is more important. Using an external preprocessor is a bit messy
> for me since it means running another tool before the synthesis tool
> is invoked .. yikes!


Yikes indeed.

Many of the tidy abstractions I enjoy when coding
a synchronous process break down when entity
ports become pins.

I prefer to write a structural top entity (wrapper) for the pins
rather than some of the more desperate measures described here.
If one of my design instances has an option,
it is already brought out to an input port.
Such an option port might be mapped to an internal register,
or I might just tie it off to '1' or '0'
This scheme would work fine for verilog or vhdl.

I let synthesis work out the details
of generating the exact hardware needed
for static or dynamic modes, and it does
a fine job of ripping out unused resources.

As long as each instanced entity has a
testbench covering all of the options,
I don't have to specifically retest these
in the top testbench.

-- Mike Treseler
 
Reply With Quote
 
 
 
 
M. Hamed
Guest
Posts: n/a
 
      10-31-2007
I thought of using two different entities representing the different
outer top level packages. However, I am recognizing that using two
entities will entail using two architectures, which defies the whole
purpose of conditional compilation since now I have to replicate
common structures between the two different architectures. On the
other hand, if I use a single architecture with generate statements, I
will still need two top level entities one for each FPGA target. Now
to associate an entity with the common architecture means I will have
to go through a preprocessing step which brings us back to square 1. I
am stuck!

On Oct 30, 1:48 pm, Mike Treseler <(E-Mail Removed)> wrote:
> M. Hamed wrote:
> > I think I will go with the two entities (two architectures?)
> > approach. It makes it easier to understand and maintain. I agree the
> > other two options are ugly however I don't totally agree they're
> > better than a preprocessor. I think a built-in VHDL preprocessor that
> > is recognized by the synthesis tool would have made my life easier.
> > After all this is a medium size VHDL project after which my group
> > management decided to switch to Verilog. It doesn't really pay to
> > strictly adhere to VHDL standard and conceptions when getting the job
> > done is more important. Using an external preprocessor is a bit messy
> > for me since it means running another tool before the synthesis tool
> > is invoked .. yikes!

>
> Yikes indeed.
>
> Many of the tidy abstractions I enjoy when coding
> a synchronous process break down when entity
> ports become pins.
>
> I prefer to write a structural top entity (wrapper) for the pins
> rather than some of the more desperate measures described here.
> If one of my design instances has an option,
> it is already brought out to an input port.
> Such an option port might be mapped to an internal register,
> or I might just tie it off to '1' or '0'
> This scheme would work fine for verilog or vhdl.
>
> I let synthesis work out the details
> of generating the exact hardware needed
> for static or dynamic modes, and it does
> a fine job of ripping out unused resources.
>
> As long as each instanced entity has a
> testbench covering all of the options,
> I don't have to specifically retest these
> in the top testbench.
>
> -- Mike Treseler



 
Reply With Quote
 
 
 
 
M. Hamed
Guest
Posts: n/a
 
      10-31-2007
Reading Andy's description again, I found that I misunderstood on a
first reading. Now I think it's the cleanest solution and worth a try.
Two entities/Two architectures that instantiates a common structure
with a generic passed to personalize the structure.

Thanks all for the suggestions.

On Oct 30, 5:01 pm, "M. Hamed" <(E-Mail Removed)> wrote:
> I thought of using two different entities representing the different
> outer top level packages. However, I am recognizing that using two
> entities will entail using two architectures, which defies the whole
> purpose of conditional compilation since now I have to replicate
> common structures between the two different architectures. On the
> other hand, if I use a single architecture with generate statements, I
> will still need two top level entities one for each FPGA target. Now
> to associate an entity with the common architecture means I will have
> to go through a preprocessing step which brings us back to square 1. I
> am stuck!
>
> On Oct 30, 1:48 pm, Mike Treseler <(E-Mail Removed)> wrote:
>
> > M. Hamed wrote:
> > > I think I will go with the two entities (two architectures?)
> > > approach. It makes it easier to understand and maintain. I agree the
> > > other two options are ugly however I don't totally agree they're
> > > better than a preprocessor. I think a built-in VHDL preprocessor that
> > > is recognized by the synthesis tool would have made my life easier.
> > > After all this is a medium size VHDL project after which my group
> > > management decided to switch to Verilog. It doesn't really pay to
> > > strictly adhere to VHDL standard and conceptions when getting the job
> > > done is more important. Using an external preprocessor is a bit messy
> > > for me since it means running another tool before the synthesis tool
> > > is invoked .. yikes!

>
> > Yikes indeed.

>
> > Many of the tidy abstractions I enjoy when coding
> > a synchronous process break down when entity
> > ports become pins.

>
> > I prefer to write a structural top entity (wrapper) for the pins
> > rather than some of the more desperate measures described here.
> > If one of my design instances has an option,
> > it is already brought out to an input port.
> > Such an option port might be mapped to an internal register,
> > or I might just tie it off to '1' or '0'
> > This scheme would work fine for verilog or vhdl.

>
> > I let synthesis work out the details
> > of generating the exact hardware needed
> > for static or dynamic modes, and it does
> > a fine job of ripping out unused resources.

>
> > As long as each instanced entity has a
> > testbench covering all of the options,
> > I don't have to specifically retest these
> > in the top testbench.

>
> > -- Mike Treseler



 
Reply With Quote
 
Brian Drummond
Guest
Posts: n/a
 
      10-31-2007
On Wed, 31 Oct 2007 00:01:58 -0000, "M. Hamed" <(E-Mail Removed)> wrote:

>I thought of using two different entities representing the different
>outer top level packages. However, I am recognizing that using two
>entities will entail using two architectures, which defies the whole
>purpose of conditional compilation since now I have to replicate
>common structures between the two different architectures.


Alternatively, those two architectures each do one thing only:
instantiate the real (superset) entity, with appropriate ports left
open.

- Brian

 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      10-31-2007
On Oct 30, 8:01 pm, "M. Hamed" <(E-Mail Removed)> wrote:
> I thought of using two different entities representing the different
> outer top level packages. However, I am recognizing that using two
> entities will entail using two architectures, which defies the whole
> purpose of conditional compilation since now I have to replicate
> common structures between the two different architectures. On the
> other hand, if I use a single architecture with generate statements, I
> will still need two top level entities one for each FPGA target. Now
> to associate an entity with the common architecture means I will have
> to go through a preprocessing step which brings us back to square 1. I
> am stuck!
>

The top level of the designs should simply instantiate the superset so
there won't need to be copying of records, types, etc. just connect up
ports.

A 'not too bad to maintain' way of having a single entity would be, as
Andy suggested simply use a single inout std_logic_vector where the
vector index is the package pin number (i.e. std_logic_vector(1 to
132) for a 132 pin QFP). A generic passed into the top level would be
used to determine the vector width of the top level entity. Within
the generate statement of the single architecture you would map the
single std_logic_vector port of the top level to the appropriate
signals of the superset entity.

All this does is attempt to put a tidy bow on a somewhat ugly solution
by essentially taking the pin numbering and using it pretty much
directly at the top level of the VHDL code. Although I prefer to keep
physical pin numbering information out of the VHDL and have it only
with the synthesis tool, it sounds like in this case, your preference,
at least in this case, would be to having a single entity as long as
it's not a really ugly solution.

Typically, with every FPGA design, I'll also have a spreadsheet which
has a line for each I/O pin that contains info like pin numbering, I/O
drive strength, setup/hold times, etc. That spreadsheet computes the
appropriate TCL commands that I copy/paste into the synthesis tool.
In this case you could have it compute the appropriate signal mappings
or other VHDL code for that top level. It's basically using a
spreadsheet as the master reference for a lot of the synthesis
information and as a code generator. A few comments surrounding the
copy/paste area in the .VHD file pointing the reader back to the
spreadsheet that is the master reference 'should' be good enough
documentation that people won't start editing that section of the file
directly.

Left as an exercise to the motivated would be how to nicely handle BGA
pin numbering (I'm thinking a 2D vector would be more appropriate) or
(worse) if you want a single entity that handles either linear
numbering (as in QFP) or grid style (as in BGA). This last situation
might best be handled again as a 2D array where the first element is
always constant.

KJ

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Type of actual ports is not compatible with type of ports of entity. mreister VHDL 1 05-25-2010 11:30 AM
Using logging module for conditional nested logs Reckoner Python 4 11-07-2009 11:45 AM
Re: module docstring, documentation,anything? please note is the module type/object NOT some module Maric Michaud Python 0 06-24-2006 12:42 PM
Recommendations Please for a PCI card w/ two USB 2 Ports and FireWaire Ports Mike Digital Photography 27 02-26-2006 12:54 AM
? ELSE Conditional Comment / Using Conditional Comments Inside Other Tags To Comment Out Attributes Alec S. HTML 10 04-16-2005 02:21 AM



Advertisments