alspin attribute

Discussion in 'VHDL' started by alessandro basili, Sep 5, 2006.

  1. Hi everyone,
    I use to add the pin assignment directly in the code (it happened to
    many times that I forgot to export the assignment file from the fitter
    and all the job was gone!!). Synplify allows you to insert the pinout
    simly adding the lines:

    attribute alspin : string;
    attribute alspin of clk : signal is "123";

    and everything is fine. What I cannot manage to do is to assign the
    pinout value to a signal that is actually an array. If address (3 downto
    0) would be instead of the previous clk, how do I assign the correct
    value to each bit? I tried this:

    attribute alspin of address (0): signal is "123";
    attribute alspin of address (1): signal is "124";
    attribute alspin of address (2): signal is "125";
    attribute alspin of address (3): signal is "126";

    and this

    attribute alspin of address : signal is ("123", "124", "125", "126");

    but without success!
    Can anyone help me?

    Thanks a lot

    Alessandro Basili
    alessandro basili, Sep 5, 2006
    #1
    1. Advertising

  2. alessandro basili wrote:

    > I use to add the pin assignment directly in the code (it happened to
    > many times that I forgot to export the assignment file from the fitter
    > and all the job was gone!!).


    I prefer to keep the pin assignments in a separate
    file because sometimes a top design entity is
    itself instanced in a later design.

    > I tried this:
    > attribute alspin of address (0): signal is "123";


    how about address[0]
    or address(0)
    or address_0
    or address0

    -- Mike Treseler
    Mike Treseler, Sep 5, 2006
    #2
    1. Advertising

  3. Mike Treseler wrote:
    > alessandro basili wrote:
    >
    >
    >>I use to add the pin assignment directly in the code (it happened to
    >>many times that I forgot to export the assignment file from the fitter
    >>and all the job was gone!!).

    >
    >
    > I prefer to keep the pin assignments in a separate
    > file because sometimes a top design entity is
    > itself instanced in a later design.
    >


    I use to have a top file with pinout and just the logic component. In
    this case I can use the same logic just changing the top entity.

    >
    >>I tried this:
    >>attribute alspin of address (0): signal is "123";

    >
    >
    > how about address[0]
    > or address(0)
    > or address_0
    > or address0
    >
    > -- Mike Treseler


    square brackets are not allowed as well as round brackets in that
    position. The other two are not really understood by the compiler,
    because they just look as different signals.

    Thanks anyway
    alessandro basili, Sep 6, 2006
    #3
  4. alessandro basili

    KJ Guest

    alessandro basili wrote:
    > Hi everyone,
    > I use to add the pin assignment directly in the code (it happened to
    > many times that I forgot to export the assignment file from the fitter
    > and all the job was gone!!). Synplify allows you to insert the pinout
    > simly adding the lines:
    >
    > attribute alspin : string;
    > attribute alspin of clk : signal is "123";
    >
    > and everything is fine. What I cannot manage to do is to assign the
    > pinout value to a signal that is actually an array. If address (3 downto
    > 0) would be instead of the previous clk, how do I assign the correct
    > value to each bit? I tried this:
    >
    > attribute alspin of address (0): signal is "123";
    > attribute alspin of address (1): signal is "124";
    > attribute alspin of address (2): signal is "125";
    > attribute alspin of address (3): signal is "126";
    >
    > and this
    >
    > attribute alspin of address : signal is ("123", "124", "125", "126");
    >
    > but without success!
    > Can anyone help me?
    >

    Maybe you already realize this, but the 'alspin' attribute is only for
    Actel devices. From the Synplify Online Help

    "The alspin attribute assigns the scalar or bus ports of the design to
    Actel I/O pin numbers (pad locations). Refer to the Actel databook for
    valid pin numbers."

    Further reading of that same paragraph says...
    "See Specifying Locations for Actel Bus Ports for information on
    assigning pin numbers to buses and slices. "

    Clicking on that link leads to the following page....

    Specifying Locations for Actel Bus Ports
    You can specify pin locations for Actel bus ports, except the 500K and
    PA technologies. To assign pin numbers to a bus port, or to a single-
    or multiple-bit slice of a bus port, do the following:
    Open the constraint file an add these attributes to the design.

    Specify the syn_noarrayports attribute globally to bit blast all bus
    ports in the design.

    define_global_attribute syn_noarrayports {1};

    Use the alspin attribute to specify pin locations for individual bus
    bits. This example shows locations specified for individual bits of bus
    ADDRESS0.

    define_attribute {ADDRESS0[4]} alspin {26}
    define_attribute {ADDRESS0[3]} alspin {30}
    define_attribute {ADDRESS0[2]} alspin {33}
    define_attribute {ADDRESS0[1]} alspin {38}
    define_attribute {ADDRESS0[0]} alspin {40}

    The software forward-annotates these pin locations to the
    place-and-route software.

    As Mike pointed out, as a general rule you do not want to embed this
    type of information in your HDL but in case you do now you know how.
    Enjoy.

    KJ
    KJ, Sep 6, 2006
    #4
  5. KJ wrote:
    > alessandro basili wrote:
    >
    >>Hi everyone,
    >>I use to add the pin assignment directly in the code (it happened to
    >>many times that I forgot to export the assignment file from the fitter
    >>and all the job was gone!!). Synplify allows you to insert the pinout
    >>simly adding the lines:
    >>
    >>attribute alspin : string;
    >>attribute alspin of clk : signal is "123";
    >>
    >>and everything is fine. What I cannot manage to do is to assign the
    >>pinout value to a signal that is actually an array. If address (3 downto
    >>0) would be instead of the previous clk, how do I assign the correct
    >>value to each bit? I tried this:
    >>
    >>attribute alspin of address (0): signal is "123";
    >>attribute alspin of address (1): signal is "124";
    >>attribute alspin of address (2): signal is "125";
    >>attribute alspin of address (3): signal is "126";
    >>
    >>and this
    >>
    >>attribute alspin of address : signal is ("123", "124", "125", "126");
    >>
    >>but without success!
    >>Can anyone help me?
    >>

    >
    > Maybe you already realize this, but the 'alspin' attribute is only for
    > Actel devices. From the Synplify Online Help
    >
    > "The alspin attribute assigns the scalar or bus ports of the design to
    > Actel I/O pin numbers (pad locations). Refer to the Actel databook for
    > valid pin numbers."
    >
    > Further reading of that same paragraph says...
    > "See Specifying Locations for Actel Bus Ports for information on
    > assigning pin numbers to buses and slices. "
    >
    > Clicking on that link leads to the following page....
    >
    > Specifying Locations for Actel Bus Ports
    > You can specify pin locations for Actel bus ports, except the 500K and
    > PA technologies. To assign pin numbers to a bus port, or to a single-
    > or multiple-bit slice of a bus port, do the following:
    > Open the constraint file an add these attributes to the design.
    >
    > Specify the syn_noarrayports attribute globally to bit blast all bus
    > ports in the design.
    >
    > define_global_attribute syn_noarrayports {1};
    >
    > Use the alspin attribute to specify pin locations for individual bus
    > bits. This example shows locations specified for individual bits of bus
    > ADDRESS0.
    >
    > define_attribute {ADDRESS0[4]} alspin {26}
    > define_attribute {ADDRESS0[3]} alspin {30}
    > define_attribute {ADDRESS0[2]} alspin {33}
    > define_attribute {ADDRESS0[1]} alspin {38}
    > define_attribute {ADDRESS0[0]} alspin {40}
    >
    > The software forward-annotates these pin locations to the
    > place-and-route software.
    >
    > As Mike pointed out, as a general rule you do not want to embed this
    > type of information in your HDL but in case you do now you know how.
    > Enjoy.
    >
    > KJ
    >


    I read this part of the documentation but the problem is that this type
    of constraints is not embedded in the code, it is just a .sdc file put
    somewhere. The reason why I want it in the code is because I use Libero
    IDE and many times I had problems like loosing file because overwritten
    or written somewhere else in some others directories. That's why I
    started including everything in the code, to be more sure that the
    program would have not create any problem.
    alessandro basili, Sep 6, 2006
    #5
  6. alessandro basili

    KJ Guest

    "alessandro basili" <> wrote in message
    news:edm9he$1fe$...
    >
    >
    > I read this part of the documentation but the problem is that this type of
    > constraints is not embedded in the code, it is just a .sdc file put
    > somewhere. The reason why I want it in the code is because I use Libero
    > IDE and many times I had problems like loosing file because overwritten or
    > written somewhere else in some others directories. That's why I started
    > including everything in the code, to be more sure that the program would
    > have not create any problem.


    One other thing that I've seen a while back (not with Synplify
    though....forget which tool to be honest, but it did have to do with
    assigning attributes to bits of a bus) is that since the attribute is
    defined to be a string and is defined to be something that is assigned to a
    signal (and not a slice which is what address(0) is or a component or an
    entity or....) is that the tool expected you to concatenate the pin numbers
    (or whatever attribute you wanted) into one big string.

    For your example, what you had is...

    attribute alspin : string;

    attribute alspin of address (0): signal is "123";
    attribute alspin of address (1): signal is "124";
    attribute alspin of address (2): signal is "125";
    attribute alspin of address (3): signal is "126";

    What the other tool wanted (and maybe Synplify does too) is
    attribute alspin of address: signal is "123,124,125,126";

    That way the actual signal address (and not the slice of a signal) is
    receiving the string attribute that it expects which it should then
    dutifully pass along to the back end tool. Assuming this is what is going
    on, then you probably need to take care about the ordering and how address
    is defined. If it works at all, then the above attribute is probably
    correct if you have defined address(0 to 3) but is probably backwards if you
    have defined it in the more customary manner of address(3 downto 0).

    Since you're using Actel (I'm assuming based on the fact that the Synplify
    help said that this attribute is only for certain Actel devices) you should
    probably dig into the Actel documentation for how one goes about specifying
    attributes in the source code.

    You didn't really say, but I'm guessing that Synplify is choking on the
    various combinations you've tried (might want to post the error message, and
    which tool was complaining, it would help, wouldn't have to be guessing
    then), but I think the problems you've hit has to do with that address(x) is
    not a signal but is a slice of a signal and that 'alspin' is an attribute
    that can be assigned to a signal (not a slice of a signal). What I've given
    you above should at least get it through Synplify. If it does, then
    hopefully it will get you through the fitter as well.

    KJ
    KJ, Sep 7, 2006
    #6
  7. Unfortunately I already tried it, but the problem is that
    "123,124,125,126" is a string, so Synplify does not complain anything,
    but to the alspin attribute this string does not make any sense (this is
    my understanding). This is very dependent on the synthesizer, because
    I've already done this for the Altera, using Quartus and the syntax was
    more or less this:

    attribute chip_pin : string;
    attribute chip_pin of address : signal is "@123,@124,@125,@126"

    In this case the string was interpreted as an "array of string", let's
    say, assigning the correct attribute to any bit of the bus.
    Maybe I'm wrong but is a matter of string...

    AB

    KJ wrote:

    >"alessandro basili" <> wrote in message
    >news:edm9he$1fe$...
    >
    >
    >>I read this part of the documentation but the problem is that this type of
    >>constraints is not embedded in the code, it is just a .sdc file put
    >>somewhere. The reason why I want it in the code is because I use Libero
    >>IDE and many times I had problems like loosing file because overwritten or
    >>written somewhere else in some others directories. That's why I started
    >>including everything in the code, to be more sure that the program would
    >>have not create any problem.
    >>
    >>

    >
    >One other thing that I've seen a while back (not with Synplify
    >though....forget which tool to be honest, but it did have to do with
    >assigning attributes to bits of a bus) is that since the attribute is
    >defined to be a string and is defined to be something that is assigned to a
    >signal (and not a slice which is what address(0) is or a component or an
    >entity or....) is that the tool expected you to concatenate the pin numbers
    >(or whatever attribute you wanted) into one big string.
    >
    >For your example, what you had is...
    >
    >attribute alspin : string;
    >
    >attribute alspin of address (0): signal is "123";
    >attribute alspin of address (1): signal is "124";
    >attribute alspin of address (2): signal is "125";
    >attribute alspin of address (3): signal is "126";
    >
    >What the other tool wanted (and maybe Synplify does too) is
    >attribute alspin of address: signal is "123,124,125,126";
    >
    >That way the actual signal address (and not the slice of a signal) is
    >receiving the string attribute that it expects which it should then
    >dutifully pass along to the back end tool. Assuming this is what is going
    >on, then you probably need to take care about the ordering and how address
    >is defined. If it works at all, then the above attribute is probably
    >correct if you have defined address(0 to 3) but is probably backwards if you
    >have defined it in the more customary manner of address(3 downto 0).
    >
    >Since you're using Actel (I'm assuming based on the fact that the Synplify
    >help said that this attribute is only for certain Actel devices) you should
    >probably dig into the Actel documentation for how one goes about specifying
    >attributes in the source code.
    >
    >You didn't really say, but I'm guessing that Synplify is choking on the
    >various combinations you've tried (might want to post the error message, and
    >which tool was complaining, it would help, wouldn't have to be guessing
    >then), but I think the problems you've hit has to do with that address(x) is
    >not a signal but is a slice of a signal and that 'alspin' is an attribute
    >that can be assigned to a signal (not a slice of a signal). What I've given
    >you above should at least get it through Synplify. If it does, then
    >hopefully it will get you through the fitter as well.
    >
    >KJ
    >
    >
    >
    >
    alessandro basili, Sep 7, 2006
    #7
  8. alessandro basili

    KJ Guest

    "alessandro basili" <> wrote in message
    news:edodj5$hdf$...
    > Unfortunately I already tried it, but the problem is that
    > "123,124,125,126" is a string, so Synplify does not complain anything, but
    > to the alspin attribute this string does not make any sense (this is my
    > understanding). This is very dependent on the synthesizer, because I've
    > already done this for the Altera, using Quartus and the syntax was more or
    > less this:
    >
    > attribute chip_pin : string;
    > attribute chip_pin of address : signal is "@123,@124,@125,@126"
    >
    > In this case the string was interpreted as an "array of string", let's
    > say, assigning the correct attribute to any bit of the bus.


    Yes, but this interpretation as an 'array of strings' can only be done
    within the context of the whole attribute setting first being a single VHDL
    string. By that I mean that "@123,@124,@125,@126" is simply a VHDL string
    whereas things like "123", "124".... are not which means that simply from a
    VHDL language perspective it is not valid code.

    Like I mentioned in the last post, what it sounds like you to do is check
    the Actel documentation (or FAE or someone) for an example of how you can
    assign attributes to a signal that is a vector. I don't think the issue is
    with Synplify. Synplify has a method for assigning pins that you can't
    follow because it puts this info in a separate constraint file instead of
    the source and the single string method is the 'generic' way to pass any
    attribute through but you basically don't know what format the Actel fitter
    wants to see for that single string....so Actel would be the best source for
    that info given that it doesn't appear that anyone on this newsgroup has
    been able to chime in with what the correct syntax for that single string
    should be.

    KJ
    KJ, Sep 7, 2006
    #8
  9. alessandro basili wrote:
    > Unfortunately I already tried it, but the problem is that
    > "123,124,125,126" is a string, so Synplify does not complain anything,
    > but to the alspin attribute this string does not make any sense (this is
    > my understanding). This is very dependent on the synthesizer, because
    > I've already done this for the Altera, using Quartus and the syntax was
    > more or less this:



    I've just updated my list of reasons to
    keep the pin assignments in a separate
    file at the place+route level.

    1. Sometimes a top design entity is
    itself instanced in a later design.

    2. Sometimes it is more trouble than
    it is worth to get the tool chain
    to pass on the pin information.


    -- Mike Treseler
    Mike Treseler, Sep 7, 2006
    #9
  10. Mike Treseler wrote:
    >
    > I've just updated my list of reasons to
    > keep the pin assignments in a separate
    > file at the place+route level.
    >
    > 1. Sometimes a top design entity is
    > itself instanced in a later design.


    You can really do the same, the only difference is that instead of the
    top you use the second level. I usually put just the assignment in the
    first level, so that all that follows is reusable without any
    modification in other projects.

    >
    > 2. Sometimes it is more trouble than
    > it is worth to get the tool chain
    > to pass on the pin information.
    >


    Once you know how to do is much easier than using different tools with
    their own unportable files.
    But I understand your point of view and I surely never meant that this
    methodology is "the best", I only feel more confindent doing it than
    some other ways, but there can be one day when I found a better way to
    me and make up my mind again ;-)

    Thanks for all opinions.

    Alessandro Basili

    >
    > -- Mike Treseler
    alessandro basili, Sep 8, 2006
    #10
    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. Bostonasian
    Replies:
    1
    Views:
    806
    Joris Gillis
    Sep 18, 2005
  2. Replies:
    2
    Views:
    1,064
    Henry S. Thompson
    Mar 6, 2006
  3. Donnal Walter

    class attribute to instance attribute

    Donnal Walter, Jun 30, 2005, in forum: Python
    Replies:
    4
    Views:
    447
    Greg Ewing
    Jul 6, 2005
  4. Russell Warren
    Replies:
    5
    Views:
    455
    Russell Warren
    Jan 17, 2006
  5. anonymous
    Replies:
    1
    Views:
    5,920
Loading...

Share This Page