Zero Replication

Hi,

I'm currently trying to have a scalable parameter of alternating bits
in a vector, e.g. 101010101.

The code I use for Modelsim to do this as follows:

parameter width = 10;

parameter alt = { {(width%2){1'b1}}, {(width/2){2'b01}} };

The first term in the concatenation is to add another 1'b1 at the most
significant bit if width is an odd number, e.g.

if width = 5,

alt = 10101

But if width is an even number, {(width%2){1'b1}} should produce zero
replications.

However, it seems that neither Modelsim nor Synplify likes zero
replications, where Modelsim simply adds a 1'b0 whenever a zero
replication is encountered.

Does anyone have any ideas of how to workaround this?

Thanks a lot.

cheers

 

[Kevin Neilson]

melvin.jc@gmail.com wrote:

Hi,

I'm currently trying to have a scalable parameter of alternating bits
in a vector, e.g. 101010101.

The code I use for Modelsim to do this as follows:

parameter width = 10;

parameter alt = { {(width%2){1'b1}}, {(width/2){2'b01}} };

The first term in the concatenation is to add another 1'b1 at the most
significant bit if width is an odd number, e.g.

if width = 5,

alt = 10101

But if width is an even number, {(width%2){1'b1}} should produce zero
replications.

However, it seems that neither Modelsim nor Synplify likes zero
replications, where Modelsim simply adds a 1'b0 whenever a zero
replication is encountered.

Does anyone have any ideas of how to workaround this?

Thanks a lot.

cheers
I don't know what the LRM says, but I've found the tools usually don't

like to replicate something zero times. There are many inelegant
workarounds. This one seems simple:

parameter wide_alt = {128{2'b01}};
parameter alt = wide_alt[width-1:0];

or even this might do:

parameter [width-1:0] alt = {128{2'b01}}; // MSBs are stripped off
// during assignment
-Kevin

 

[Kevin Neilson]

melvin.jc@gmail.com wrote:

Hi,

I'm currently trying to have a scalable parameter of alternating bits
in a vector, e.g. 101010101.

The code I use for Modelsim to do this as follows:

parameter width = 10;

parameter alt = { {(width%2){1'b1}}, {(width/2){2'b01}} };

The first term in the concatenation is to add another 1'b1 at the most
significant bit if width is an odd number, e.g.

if width = 5,

alt = 10101

But if width is an even number, {(width%2){1'b1}} should produce zero
replications.

However, it seems that neither Modelsim nor Synplify likes zero
replications, where Modelsim simply adds a 1'b0 whenever a zero
replication is encountered.

Does anyone have any ideas of how to workaround this?

Thanks a lot.

cheers

Just for fun, I checked the LRM to see if this is legal. It is, though
that doesn't mean the tools support it. The LRM uses an example similar
to your code:

A replication operation may have a replication constant with a value of
zero. This is useful in parameterized code. A replication with a zero
replication constant is considered to have a size of zero and is
ignored. Such a replication shall appear only within a concatenation in
which at least one of the operands of the concatenation has a positive size.
For example:
parameter P = 32;
// The following is legal for all P from 1 to 32
assign b[31:0] = { {32-P{1’b1}}, a[P-1:0] } ;

 

[Muzaffer Kal]

On Fri, 11 Jul 2008 13:41:38 -0700 (PDT), melvin.jc@gmail.com wrote:

Hi,

I'm currently trying to have a scalable parameter of alternating bits
in a vector, e.g. 101010101.

The code I use for Modelsim to do this as follows:

parameter width = 10;

parameter alt = { {(width%2){1'b1}}, {(width/2){2'b01}} };

The first term in the concatenation is to add another 1'b1 at the most
significant bit if width is an odd number, e.g.

if width = 5,

alt = 10101

But if width is an even number, {(width%2){1'b1}} should produce zero
replications.

However, it seems that neither Modelsim nor Synplify likes zero
replications, where Modelsim simply adds a 1'b0 whenever a zero
replication is encountered.

Does anyone have any ideas of how to workaround this?

Unfortunately you can't. The standard says "the first expression shall
be a non-zero ... expression".

 

[Muzaffer Kal]

On Fri, 11 Jul 2008 16:34:24 -0600, Kevin Neilson
<kevin_neilson@removethiscomcast.net> wrote:

melvin.jc@gmail.com wrote:
Hi,

I'm currently trying to have a scalable parameter of alternating bits
in a vector, e.g. 101010101.

The code I use for Modelsim to do this as follows:

parameter width = 10;

parameter alt = { {(width%2){1'b1}}, {(width/2){2'b01}} };

The first term in the concatenation is to add another 1'b1 at the most
significant bit if width is an odd number, e.g.

if width = 5,

alt = 10101

But if width is an even number, {(width%2){1'b1}} should produce zero
replications.

However, it seems that neither Modelsim nor Synplify likes zero
replications, where Modelsim simply adds a 1'b0 whenever a zero
replication is encountered.

Does anyone have any ideas of how to workaround this?

Thanks a lot.

cheers

Just for fun, I checked the LRM to see if this is legal. It is, though
that doesn't mean the tools support it. The LRM uses an example similar
to your code:

A replication operation may have a replication constant with a value of
zero.

Curious. The document I'm looking at (1364-2001) says "the first
expression shall be a non-zero ... expression". Where do you see the
quote above?

 

[Muzaffer Kal]

On Fri, 11 Jul 2008 16:34:24 -0600, Kevin Neilson
<kevin_neilson@removethiscomcast.net> wrote:

melvin.jc@gmail.com wrote:
Hi,

I'm currently trying to have a scalable parameter of alternating bits
in a vector, e.g. 101010101.

The code I use for Modelsim to do this as follows:

parameter width = 10;

parameter alt = { {(width%2){1'b1}}, {(width/2){2'b01}} };

The first term in the concatenation is to add another 1'b1 at the most
significant bit if width is an odd number, e.g.

if width = 5,

alt = 10101

But if width is an even number, {(width%2){1'b1}} should produce zero
replications.

However, it seems that neither Modelsim nor Synplify likes zero
replications, where Modelsim simply adds a 1'b0 whenever a zero
replication is encountered.

Does anyone have any ideas of how to workaround this?

Thanks a lot.

cheers

Just for fun, I checked the LRM to see if this is legal. It is, though
that doesn't mean the tools support it. The LRM uses an example similar
to your code:

A replication operation may have a replication constant with a value of
zero.

I think this is from 1364-2005. Till draft 3 it said non-zero or
positive so they must have changed it later. The best course of action
would be to file bugs against tools which don't conform after
verifying that your vendor claims 1364-2005 compliance.

 

[Kevin Neilson]

Muzaffer Kal wrote:

On Fri, 11 Jul 2008 16:34:24 -0600, Kevin Neilson
kevin_neilson@removethiscomcast.net> wrote:

melvin.jc@gmail.com wrote:
Hi,

I'm currently trying to have a scalable parameter of alternating bits
in a vector, e.g. 101010101.

The code I use for Modelsim to do this as follows:

parameter width = 10;

parameter alt = { {(width%2){1'b1}}, {(width/2){2'b01}} };

The first term in the concatenation is to add another 1'b1 at the most
significant bit if width is an odd number, e.g.

if width = 5,

alt = 10101

But if width is an even number, {(width%2){1'b1}} should produce zero
replications.

However, it seems that neither Modelsim nor Synplify likes zero
replications, where Modelsim simply adds a 1'b0 whenever a zero
replication is encountered.

Does anyone have any ideas of how to workaround this?

Thanks a lot.

cheers
Just for fun, I checked the LRM to see if this is legal. It is, though
that doesn't mean the tools support it. The LRM uses an example similar
to your code:

A replication operation may have a replication constant with a value of
zero.

Curious. The document I'm looking at (1364-2001) says "the first
expression shall be a non-zero ... expression". Where do you see the
quote above?

I quoted 1364-2005, so the LRM probably changed. Even though it's been
several years since this version has been published, I'm sure
noncompliance is widespread. I've seen other instances of tools still
complying with 2001 instead of 2005 (e.g., in the details of $readmemh).
-Kevin

 

[gabor]

On Jul 14, 12:59 pm, Kevin Neilson
<kevin_neil...@removethiscomcast.net> wrote:

Muzaffer Kal wrote:
On Fri, 11 Jul 2008 16:34:24 -0600, Kevin Neilson
kevin_neil...@removethiscomcast.net> wrote:

melvin...@gmail.com wrote:
Hi,

I'm currently trying to have a scalable parameter of alternating bits
in a vector, e.g. 101010101.

The code I use for Modelsim to do this as follows:

parameter width = 10;

parameter alt = { {(width%2){1'b1}}, {(width/2){2'b01}} };

The first term in the concatenation is to add another 1'b1 at the most
significant bit if width is an odd number, e.g.

if width = 5,

alt = 10101

But if width is an even number, {(width%2){1'b1}} should produce zero
replications.

However, it seems that neither Modelsim nor Synplify likes zero
replications, where Modelsim simply adds a 1'b0 whenever a zero
replication is encountered.

Does anyone have any ideas of how to workaround this?

Thanks a lot.

cheers
Just for fun, I checked the LRM to see if this is legal. It is, though
that doesn't mean the tools support it. The LRM uses an example similar
to your code:

A replication operation may have a replication constant with a value of
zero.

Curious. The document I'm looking at (1364-2001) says "the first
expression shall be a non-zero ... expression". Where do you see the
quote above?

I quoted 1364-2005, so the LRM probably changed. Even though it's been
several years since this version has been published, I'm sure
noncompliance is widespread. I've seen other instances of tools still
complying with 2001 instead of 2005 (e.g., in the details of $readmemh).
-Kevin

Perhaps not very elegant, but what about:

parameter alt = (width%2) ? { 1'b1, {(width/2){2'b01}} } : {(width/2)
{2'b01}};

 

On Jul 14, 12:59 pm, Kevin Neilson
<kevin_neil...@removethiscomcast.net> wrote:

I quoted 1364-2005, so the LRM probably changed.  

Yes. Shalom Bresticker pushed for this change, to make it easier to
write the kind of parameterized code described here.

Zero replication counts would cause problems if they introduced zero-
width vectors into expressions. The kludgy restriction about only
appearing in a concatenation with an operand having a positive size
was intended to avoid that, while still allowing them in situations
like this one.

By far the most common situation where zero (or negative) replication
counts occur in parameterized code is for sign extension. Especially
before signed arithmetic was added in 2001, Verilog users would sign-
extend from a narrower to a wider width by replicating the MSB a
number of times equal to the difference in the source and destination
widths. If the parameterization was such that the destination width
was the same or narrower than the source width, the replication count
would become zero or negative. But in that case, it didn't really
matter what got produced for the replication, as long as it didn't
error out. Anything it produced would be discarded anyway, by
truncation on assignment to the destination. The 1'b0 that you are
seeing is as good as anything else. It is probably being produced
because that is what Verilog-XL produced when run in its "most
standard" mode (or because that is what some other simulator produced,
trying to match XL).

Even though it's been
several years since this version has been published, I'm sure
noncompliance is widespread.

Since the 1'b0 behavior works fine for the most common situations,
there isn't much incentive for implementations to change. It looks to
me like it should work fine for the situation posted here. Is there a
problem with getting an extra zero at the top?

There were not a lot of extensions in the 2005 LRM. Allowing zero
replication counts was one. Another was the addition of the uwire net
type, which allows declaring a net that is only allowed to have one
driver, giving an error if you mistakenly attach more than one. Then
there was the addition of a variety of math functions as system
functions, and allowing these and a few previous system functions in
constant expressions.

The 2005 LRM also fixed a lot of problems in the 2001 LRM. The most
significant is the reworking of how generates work, since the
specification in the 2001 LRM was not practical to implement as
specified. I would hope that implementations have at least followed
that part.

 I've seen other instances of tools still
complying with 2001 instead of 2005 (e.g., in the details of $readmemh).

Are you talking about the issue of reading from lowest address to
highest, instead of leftmost in the range to rightmost?

That would be another case of fixing a problem, and getting the LRM to
match the de facto standard.

 

On Jul 14, 2:44 pm, gabor <ga...@alacron.com> wrote

Perhaps not very elegant, but what about:

parameter alt = (width%2) ? { 1'b1, {(width/2){2'b01}} } : {(width/2)
{2'b01}};

That would avoid any error or warning from the zero replication
count. However, it would end up giving the same result of adding a
1'b0 to the top end, as Modelsim is already doing with the zero
count. I don't know whether that matters to the original poster.

 

[Kevin Neilson]

sharp@cadence.com wrote:

On Jul 14, 12:59 pm, Kevin Neilson
kevin_neil...@removethiscomcast.net> wrote:
I quoted 1364-2005, so the LRM probably changed.



Since the 1'b0 behavior works fine for the most common situations,
there isn't much incentive for implementations to change. It looks to
me like it should work fine for the situation posted here. Is there a
problem with getting an extra zero at the top?

There is always a workaround using ifs or generates, but in general,

it's good for language constructs to be able to collapse to make them
useful for parameterization. It's good to be able to shift by zero (or
negative), replicate by zero, etc.

I've seen other instances of tools still
complying with 2001 instead of 2005 (e.g., in the details of $readmemh).

Are you talking about the issue of reading from lowest address to
highest, instead of leftmost in the range to rightmost?

That would be another case of fixing a problem, and getting the LRM to
match the de facto standard.

That was the issue, I believe--the old LRM loaded arrays differently if
they were declared low-to-high or high-to-low. You can override the
default behavior by specifying the starting address. This didn't bother
me too much, like the fact that it took five years for some synthesizers
to start supporting 'generate'. Since there were fewer big changes in
'05, the noncompliance isn't much of an issue, but it's annoying when I
have some code nicely working using the $sin function and then find it
doesn't work on some other tool even though it's now '08.
-Kevin