«

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

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

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