Conditional module ports
M. Hamed
some removed ports and internal modules for the smaller package. How
can I accomplish that with VHDL? I know I can use generate statements
to generate different logic conditionally, but how can I apply this to
the module ports?
Thank you.
Andy
Can the larger one contain the smaller one (i.e big = small + extras)?
At least the "small" one would be common to both designs.
Lower level entities could have unused ports (declared on the entity
but not hooked up in the architecture and/or left open in the
instantiating architecture, with default values for inputs &
inouts)... So you could have two "wrapper" entities that contained the
same "main" entity, which is configured via generics, etc.
Andy
M. Hamed
it on an FPGA. I strongly think that the tool will complain if any
ports are unassigned!
Andy
You may get warnings if ports on internal modules are not assigned (as
long as it is legal vhdl: in/inout ports, if left open, must have been
declared with default values, etc.), but otherwise it will be ok.
If you have ports that are not driven/used in the top level
architecture, then you will get errors...
Andy
KJ
"M. Hamed" <mhs...@gmail.com> wrote in message
news:1193694295.4...@v23g2000prn.googlegroups.com...
> Thanks for your suggestion. I need to synthesize this design and fit
> it on an FPGA. I strongly think that the tool will complain if any
> ports are unassigned!
>
can be left unconnected if the entity defines a default value for the
signal. Works for simulation and synthesis. If your synthesis tool
complains you have a bad tool, get a better one.
Ex:
entity foo is port(
Some_Input: std_logic; -- No default, must connect
Some_Input2: std_logic := '0'; -- Can leave left open
Some_Output: std_logic);
end foo;
One possible instantiation is...
My_Foo : entity work.foo port map(Some_Input => Some_Signal);
KJ
Uncle Noah
Hi
"conditional" is the magic word for you. You need not (or you better
not) mess with tricks to create the effect of conditional ports. It is
simpler to preprocess your VHDL source code via (e.g.) the "kpp"
preprocessor or something equivalent.
Nikolaos Kavvadias
Thomas Stanka
> On Oct 29, 8:18 pm, "M. Hamed" <mhs...@gmail.com> wrote:
>
> > I have a design that should accommodates two different packages with
> > some removed ports and internal modules for the smaller package. How
> > can I accomplish that with VHDL? I know I can use generate statements
> > to generate different logic conditionally, but how can I apply this to
> > the module ports?
>
> > Thank you.
>
> not) mess with tricks to create the effect of conditional ports. It is
> simpler to preprocess your VHDL source code via (e.g.) the "kpp"
> preprocessor or something equivalent.
I Disagree. In my opinion it is better to use configurations and
generics than preprocessors. This is valid vhdl, so every tool knows
how to handle them.
OK, made a joke s/every tool/every good tool/.
bye Thomas
KJ
"Thomas Stanka" <usenet_no...@stanka-web.de> wrote in message
news:1193724810....@50g2000hsm.googlegroups.com...
You're both making this harder than it needs to be with pre-processors (bad
since it goes outside the language) and configuration statements (not needed
and possibly not well supported for synthesis...haven't checked on this
lately though). The poster was simply asking about not connecting signals
to a given entity because that particular instantiation does not support all
of the bells and whistles that another instantiation might. There is no
need for anything conditional about the entity itself, there can be
conditional logic (via the generate) if needed in the instantiation of that
entity.
KJ
Andy
> "Thomas Stanka" <usenet_nospam_va...@stanka-web.de> wrote in message
KJ, that is correct as far as it goes. But he also has different IO at
the top level based on which design and which FPGA package he is
targeting. For synthesis there is no "instantiation" of the top level
entity, so it is not a matter of leaving ports open in a port map. If
he were to use the "superset" top level entity, and just not attach to
some of the ports in the top level architecture, that would generate
errors in most synthesis tools.
Lower level entities can have portions of their port maps left open
(under the rules of vhdl), and only generate warnings (if that) in a
synthesis tool. I don't see a good way of escaping having two
different top level entities (and their architectures). But the top
level architectures could instantiate the same lower level entity
(with one having some open port associations). In addition, a generic
or three could be passed to that entity to alter the internal
construction (i.e. lower level modules either left out or included).
Depending on how bad you want to have a single entity, there are some
ugly, but pure-vhdl solutions. One is to have all the IO defined as a
record, whose definition is in a package. Change the package, change
the port definitions. You can have a single record port of mode inout,
or three separate record ports of modes in, out, and inout
respectively. Beware that synthesis tools are not usually very kind
in intelligently renaming record elements into pin names.
Another related option is to combine all the IO into one (or three)
std_logic_vectors whose widths are constrained by three generics (top
level generics can be set via tool (or command-line) option during
synthesis and/or simulation. Keeping track of the bit-mapping of
individual IOs in the vectors would best be handled by named constants
in a package, or by conversion to/from a record via one or more
functions in a package (the function can be overloaded based on the
width of the vector or the type of the record). But when you are
looking at a PAR report, all the ports are just going to be numbered,
and you'll have to manually convert to individual port names.
Both of these latter options are really ugly, but IMHO, better that
resorting to a non-standard preprocessor.
Andy
M. Hamed
whole issue. I do believe the synthesis tool will generate errors if
ports at the top level are more than the target FPGA package can
handle. 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!
Mike Treseler
> 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
M. Hamed
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!
M. Hamed
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.
Brian Drummond
>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
KJ
> 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!
>
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