procedure problem

[Brian Drummond]

On Mon, 17 Dec 2012 08:28:08 +0100, Thomas Heller wrote:

Am 15.12.2012 11:20, schrieb Brian Drummond:
On Tue, 11 Dec 2012 15:52:41 +0100, Thomas Heller wrote:
Here is the procedure:

procedure advance_state (
signal state : inout state_type;
constant next_state : in state_type;
signal counter : inout integer range 0 to 1000;
constant dt : in integer)

I have just re-tested with ISE14.3.
This bug is still there targeting Spartan-3 but goes away targeting S6.

I believe this may be the bug you are seeing...

Yes it seems this is the bug. Thanks for the confirmation!

In my case it was cascading my carefully pipelined multiplications into a
single cycle (thanks to variable assignment!), delivering results several
cycles too early, and achieving a third of the intended performance!

- Brian

 

[Martin Thompson]

rickman <gnuarm@gmail.com> writes:

On 12/15/2012 4:50 AM, Brian Drummond wrote:
On Fri, 14 Dec 2012 13:10:35 -0500, rickman wrote:

We seem to be pretty much on the same page. I think the only issue is
what people mean when they say the "parser". I assume this is being
used loosely as synthesis. If someone is really saying the "parser",
that is the part that just looks at the code and turns it into internal
tokens, is technology aware, I am sure they are wrong. This makes no
sense at all.

Technology dependent /= technology aware...

The Xilinx parser is technology dependent - not because it is technology
aware, but because XST choose a new parser - yes, the bit that translates
and arranges tokens - if a new device is the target, and an old one if an
older device is the target.

Ok, this is what I mean. You are saying "parser", but you mean the synthesis
component, not really the parser.

No, he really means the parser. That "tiny bit" of the process *did*
change between 2&3-devices and 6-devices, and you have to jump through
hoops (well, give a switch and give up on support) to use it on the
older devices.

*As well* as that there are the technology specific synthesis parts - but
that's (as you say) expected to the tech dependent.

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

 

[rickman]

On 12/17/2012 8:57 AM, Brian Drummond wrote:

On Sun, 16 Dec 2012 10:22:01 -0500, rickman wrote:

On 12/15/2012 4:50 AM, Brian Drummond wrote:
On Fri, 14 Dec 2012 13:10:35 -0500, rickman wrote:

We seem to be pretty much on the same page. I think the only issue is
what people mean when they say the "parser". I assume this is being
used loosely as synthesis. If someone is really saying the "parser",
that is the part that just looks at the code and turns it into
internal tokens, is technology aware, I am sure they are wrong. This
makes no sense at all.

Technology dependent /= technology aware...

The Xilinx parser is technology dependent - not because it is
technology aware, but because XST choose a new parser - yes, the bit
that translates and arranges tokens - if a new device is the target,
and an old one if an older device is the target.

Ok, this is what I mean. You are saying "parser", but you mean the
synthesis component, not really the parser.

Xilinx really DO change the parser - the nominally tech INdependent bit -
selecting between two of them - according to device family.

You can use either new or old *parser* for the older devices - in either
case, the same tech-dependent back end is employed.

That doesn't make much sense to me. There is no reason to make the
actual parser any different because the parser only translates the ASCII
text into internal machine representations. I would expect nothing
specific to any technology other than the language being used.

I read the references you give below. I'm still not clear that you can
say the parser is technology dependent. These reports are about
properties that are outside of the language.

'The 13.3 XST Verific Parser still prevents SRL inference even if the
Save net attribute is set to "false".'

The problem is that the parser has a bug regarding some flag that
affects one device set and not others. I'm not sure this is the same
thing as saying the parser is technology dependent.

The parser just analyses the source and turns it into internal tokens
that are just machine understandable representations of the language.
This is only a small part of the synthesis process and should not be
used as the name for the entire process. Why not call it the synthesis
tool?

Because it isn't the synthesis tool. It is only the source analyzer.
The second link below suggests they bought it from Verific. It does seem
to avoid some of the old bugs, but apparently has a few of its own.

The rest of the synth tool is the same for a specific device, whichever
of the front ends (parsers) you choose.

http://forums.xilinx.com/t5/Synthesis/How-to-enable-the-new-parser-for-
XST-in-ISE-12-1/td-p/133272

http://www.xilinx.com/support/answers/45245.htm

- Brian

Thanks for the links. This makes it all clear. The fact that they
allow you to choose different parsers doesn't make them technology
specific. I think I disagree with the terminology of saying the parser
is technology specific because it has bugs in property assignments that
affect one line of parts and not another, but whatever, it's not a big
deal. I think I understand what you are saying now, so thanks.

Rick

 

[Brian Drummond]

On Tue, 18 Dec 2012 11:34:58 -0500, rickman wrote:

Thanks for the links. This makes it all clear. The fact that they
allow you to choose different parsers doesn't make them technology
specific. I think I disagree with the terminology of saying the parser
is technology specific because it has bugs in property assignments that
affect one line of parts and not another, but whatever, it's not a big
deal. I think I understand what you are saying now, so thanks.

One last try, because I think we are converging...

Neither parser - in itself - is technology specific - and I don't believe
anyone ever meant to suggest they were.

But there is a switch controlling which parser is selected - and its
setting IS a function of the selected technology.

Therefore - from an user's point of view - "the parser" as seen from
outside XST, _appears_ to be tech specific.

Would you be happy with that way of expressing it?

- Brian