Conditional module ports

Discussion in 'VHDL' started by M. Hamed, Oct 29, 2007.

  1. M. Hamed

    M. Hamed Guest

    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.
    M. Hamed, Oct 29, 2007
    #1
    1. Advertising

  2. M. Hamed

    Andy Guest

    On Oct 29, 1:18 pm, "M. Hamed" <> 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.


    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
    Andy, Oct 29, 2007
    #2
    1. Advertising

  3. M. Hamed

    M. Hamed Guest

    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!


    On Oct 29, 12:02 pm, Andy <> wrote:
    > On Oct 29, 1:18 pm, "M. Hamed" <> 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.

    >
    > 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, Oct 29, 2007
    #3
  4. M. Hamed

    Andy Guest

    On Oct 29, 4:44 pm, "M. Hamed" <> wrote:
    > 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!
    >
    > On Oct 29, 12:02 pm, Andy <> wrote:
    >
    > > On Oct 29, 1:18 pm, "M. Hamed" <> 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.

    >
    > > 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


    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
    Andy, Oct 29, 2007
    #4
  5. M. Hamed

    KJ Guest

    "M. Hamed" <> wrote in message
    news:...
    > 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!
    >

    You're mistaken. Outputs can always be left unconnected, inputs and inouts
    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
    KJ, Oct 29, 2007
    #5
  6. M. Hamed

    Uncle Noah Guest

    On Oct 29, 8:18 pm, "M. Hamed" <> 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.


    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
    Uncle Noah, Oct 30, 2007
    #6
  7. On 30 Okt., 03:46, Uncle Noah <> wrote:
    > On Oct 29, 8:18 pm, "M. Hamed" <> 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.

    >
    > "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.




    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
    Thomas Stanka, Oct 30, 2007
    #7
  8. M. Hamed

    KJ Guest

    "Thomas Stanka" <> wrote in message
    news:...
    > On 30 Okt., 03:46, Uncle Noah <> wrote:
    >> On Oct 29, 8:18 pm, "M. Hamed" <> 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.

    >>
    >> "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.

    >
    >
    >
    > 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
    >


    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
    KJ, Oct 30, 2007
    #8
  9. M. Hamed

    Andy Guest

    On Oct 30, 6:20 am, "KJ" <> wrote:
    > "Thomas Stanka" <> wrote in message
    >
    > news:...
    >
    >
    >
    > > On 30 Okt., 03:46, Uncle Noah <> wrote:
    > >> On Oct 29, 8:18 pm, "M. Hamed" <> 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.

    >
    > >> "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.

    >
    > > 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

    >
    > 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


    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
    Andy, Oct 30, 2007
    #9
  10. M. Hamed

    M. Hamed Guest

    Thanks All for the suggestions, and thanks Andy for summing up the
    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!



    On Oct 30, 6:14 am, Andy <> wrote:
    > On Oct 30, 6:20 am, "KJ" <> wrote:
    >
    >
    >
    > > "Thomas Stanka" <> wrote in message

    >
    > >news:...

    >
    > > > On 30 Okt., 03:46, Uncle Noah <> wrote:
    > > >> On Oct 29, 8:18 pm, "M. Hamed" <> 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.

    >
    > > >> "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.

    >
    > > > 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

    >
    > > 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

    >
    > 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, Oct 30, 2007
    #10
  11. 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
    Mike Treseler, Oct 30, 2007
    #11
  12. M. Hamed

    M. Hamed Guest

    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 <> 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
    M. Hamed, Oct 31, 2007
    #12
  13. M. Hamed

    M. Hamed Guest

    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" <> 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 <> 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
    M. Hamed, Oct 31, 2007
    #13
  14. On Wed, 31 Oct 2007 00:01:58 -0000, "M. Hamed" <> 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
    Brian Drummond, Oct 31, 2007
    #14
  15. M. Hamed

    KJ Guest

    On Oct 30, 8:01 pm, "M. Hamed" <> 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
    KJ, Oct 31, 2007
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alec S.
    Replies:
    10
    Views:
    10,080
    Alec S.
    Apr 16, 2005
  2. Reckoner
    Replies:
    4
    Views:
    245
    Vinay Sajip
    Nov 7, 2009
  3. Pete Emerson
    Replies:
    21
    Views:
    609
  4. mreister
    Replies:
    1
    Views:
    3,111
    mreister
    May 25, 2010
  5. David Filmer
    Replies:
    2
    Views:
    263
    C.DeRykus
    Mar 29, 2013
Loading...

Share This Page