«

On 12/12/2012 10:13 AM, Gabor wrote:
> Christopher Felton wrote:
>> On 12/11/2012 3:37 PM, Gabor wrote:
>>> Christopher Felton wrote:
>>>> On 12/11/2012 11:52 AM, Thomas Heller wrote:
>>>>> Am 11.12.2012 17:53, schrieb Christopher Felton:
>>>>>> On 12/11/2012 10:22 AM, Thomas Heller wrote:
>>>>>>> Am 11.12.2012 16:33, schrieb Pontus:
>>>>>>>> I noticed that
>>>>>>>>
>>>>>>>> signal counter : inout integer range 0 to 1000;
>>>>>>>>
>>>>>>>> and
>>>>>>>>
>>>>>>>> advance_state(state, START_B, counter, 2000);
>>>>>>>>
>>>>>>>> 2000 is not in range 0 to 1000, does this compile?
>>>>>>>
>>>>>>> This is an error that I made when copying the code into
>>>>>>> the message. I tried to simplify it a bit.
>>>>>>> Yes, it does compile, and, as I said, it does even work
>>>>>>> for Spartan 6.
>>>>>>>
>>>>>>>> Where do you increment the counter?
>>>>>>>
>>>>>>> The counter in incremented on every rising_edge(clock)
>>>>>>> elsewhere in the process.
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>
>>>>>> When you say compile, it synthesizes without errors and passes PaR
>>>>>> with
>>>>>> no timing errors (timing errors don't error out the software).
>>>>>> Unless
>>>>>> it is a resource issue, I can't see why a S3 vs. S6 would make a
>>>>>> difference.
>>>>>
>>>>> Yes, no errors, and it fits timing.
>>>>> I assume they use different parsers/map/par for s3 and s6.
>>>>> Maybe that explains the issue.
>>>>
>>>> It shouldn't have a different parser, I believe the Xilinx synthesis
>>>> is device aware but typically synthesis will synthesize to generic
>>>> primitives (gates) and then the mapper will translate to device
>>>> specific. I would expect only the mapper to be significantly
>>>> different. But there should be some kind of warning or error that
>>>> there are not enough resources etc., hmmmm.
>>>>
>>>>>
>>>>> How do others write statemachines with certain durations for the
>>>>> states?
>>>>
>>>> If you mean simple time delays, I usually have a local counter,
>>>> something like your example.. Other times I will make a generic state
>>>> delay, where the return state (next state out of the delay state) is a
>>>> register and the delay is a register. Then it is like calling a
>>>> function in CPU programming, you have to program the delay and return
>>>> state before transitioning to the delay state. It is a reusable delay
>>>> with the extra overhead of the programmable delay (expiration) and
>>>> return state. And normally it is three states, delay_start,
>>>> delay_wait, delay_end.
>>>>
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>> Regards,
>>>> Chris
>>> S6 and newer devices use the "new parser" for XST. Older devices
>>> do not, unless you add "-use_new_parser yes" to the command line
>>> options for XST. This could very well explain the difference in
>>> behavior between the two. You need ISE 12 or newer to use the
>>> new parser.
>>>
>>> -- Gabor
>>
>> Seems odd to me, wonder what the rational was. That is, a new release
>> of software to use a different parser (frontend of synthesis) for
>> different devices.
>>
>> Regards,
>> Chris
>
> The rationale is very simple actually. They didn't want to run
> regression testing on all of the older device families. They
> give you a switch to turn on (or off) the new parser regardless of
> the FPGA family, but if you decide to use the new parser on an
> older device you should not expect support.
>
> -- Gabor

I must be missing something here, when you say parser I assume the
frontend of the synthesis engine? I am having a hard time seeing the
direct connection between the "parser" and a device. I guess if you
wanted to be super paranoid you could regression test against the device
but it seems pointless?

The tools flow:

input VHDL (hardware description)
|
*Synthesis
|
output technology agnostic
structural circuit
|
*Mapper
|
output technology specific
structural circuit
|
*PaR
|
output technology and physical
details (FPGA case config stream)

*indicates the FPGA eda software.

If a 3rd party synthesis vendor changed their "parser" would they test
against all possible target devices or would they simply test enough
VHDL input test cases?

I guess the Xilinx synthesis tool must incorporate device specific
technology early on? Seems dangerous to me.

Regards,
Chris

Christopher Felton wrote:
> On 12/12/2012 10:13 AM, Gabor wrote:
>> Christopher Felton wrote:
>>> On 12/11/2012 3:37 PM, Gabor wrote:
>>>> Christopher Felton wrote:
>>>>> On 12/11/2012 11:52 AM, Thomas Heller wrote:
>>>>>> Am 11.12.2012 17:53, schrieb Christopher Felton:
>>>>>>> On 12/11/2012 10:22 AM, Thomas Heller wrote:
>>>>>>>> Am 11.12.2012 16:33, schrieb Pontus:
>>>>>>>>> I noticed that
>>>>>>>>>
>>>>>>>>> signal counter : inout integer range 0 to 1000;
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> advance_state(state, START_B, counter, 2000);
>>>>>>>>>
>>>>>>>>> 2000 is not in range 0 to 1000, does this compile?
>>>>>>>>
>>>>>>>> This is an error that I made when copying the code into
>>>>>>>> the message. I tried to simplify it a bit.
>>>>>>>> Yes, it does compile, and, as I said, it does even work
>>>>>>>> for Spartan 6.
>>>>>>>>
>>>>>>>>> Where do you increment the counter?
>>>>>>>>
>>>>>>>> The counter in incremented on every rising_edge(clock)
>>>>>>>> elsewhere in the process.
>>>>>>>>
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>
>>>>>>> When you say compile, it synthesizes without errors and passes PaR
>>>>>>> with
>>>>>>> no timing errors (timing errors don't error out the software).
>>>>>>> Unless
>>>>>>> it is a resource issue, I can't see why a S3 vs. S6 would make a
>>>>>>> difference.
>>>>>>
>>>>>> Yes, no errors, and it fits timing.
>>>>>> I assume they use different parsers/map/par for s3 and s6.
>>>>>> Maybe that explains the issue.
>>>>>
>>>>> It shouldn't have a different parser, I believe the Xilinx synthesis
>>>>> is device aware but typically synthesis will synthesize to generic
>>>>> primitives (gates) and then the mapper will translate to device
>>>>> specific. I would expect only the mapper to be significantly
>>>>> different. But there should be some kind of warning or error that
>>>>> there are not enough resources etc., hmmmm.
>>>>>
>>>>>>
>>>>>> How do others write statemachines with certain durations for the
>>>>>> states?
>>>>>
>>>>> If you mean simple time delays, I usually have a local counter,
>>>>> something like your example.. Other times I will make a generic state
>>>>> delay, where the return state (next state out of the delay state) is a
>>>>> register and the delay is a register. Then it is like calling a
>>>>> function in CPU programming, you have to program the delay and return
>>>>> state before transitioning to the delay state. It is a reusable delay
>>>>> with the extra overhead of the programmable delay (expiration) and
>>>>> return state. And normally it is three states, delay_start,
>>>>> delay_wait, delay_end.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Chris
>>>>>
>>>>> Regards,
>>>>> Chris
>>>> S6 and newer devices use the "new parser" for XST. Older devices
>>>> do not, unless you add "-use_new_parser yes" to the command line
>>>> options for XST. This could very well explain the difference in
>>>> behavior between the two. You need ISE 12 or newer to use the
>>>> new parser.
>>>>
>>>> -- Gabor
>>>
>>> Seems odd to me, wonder what the rational was. That is, a new release
>>> of software to use a different parser (frontend of synthesis) for
>>> different devices.
>>>
>>> Regards,
>>> Chris
>>
>> The rationale is very simple actually. They didn't want to run
>> regression testing on all of the older device families. They
>> give you a switch to turn on (or off) the new parser regardless of
>> the FPGA family, but if you decide to use the new parser on an
>> older device you should not expect support.
>>
>> -- Gabor
>
> I must be missing something here, when you say parser I assume the
> frontend of the synthesis engine? I am having a hard time seeing the
> direct connection between the "parser" and a device. I guess if you
> wanted to be super paranoid you could regression test against the device
> but it seems pointless?
>
> The tools flow:
>
> input VHDL (hardware description)
> |
> *Synthesis
> |
> output technology agnostic
> structural circuit
> |
> *Mapper
> |
> output technology specific
> structural circuit
> |
> *PaR
> |
> output technology and physical
> details (FPGA case config stream)
>
> *indicates the FPGA eda software.
>
> If a 3rd party synthesis vendor changed their "parser" would they test
> against all possible target devices or would they simply test enough
> VHDL input test cases?
>
> I guess the Xilinx synthesis tool must incorporate device specific
> technology early on? Seems dangerous to me.
>
> Regards,
> Chris
>
By "parser," Xilinx means their synthesis front-end. And yes, it
does have some technology-awareness. This makes sense when you
realize that they only target their own devices, and that the
third-party synthesis engines have a longstanding advantage at
doing synthesis well in the traditional way. For newer versions
of XST, "synthesis" also includes the first stage of mapping, including
packing logic elements into slices. So there is not such a clear
line in terms of where the "parser" ends and the "physical synthesis"
begins. Thus, you would presume that a large amount of testing
would be needed to fully support the older devices, even when only
the "parser" changes.

-- Gabor

You guys need to learn to snip...

On 12/12/2012 11:50 AM, Christopher Felton wrote:
>
> I must be missing something here, when you say parser I assume the
> frontend of the synthesis engine? I am having a hard time seeing the
> direct connection between the "parser" and a device. I guess if you
> wanted to be super paranoid you could regression test against the device
> but it seems pointless?
>
> The tools flow:
>
> input VHDL (hardware description)
> |
*Synthesis front end
> |
> output technology agnostic
> structural circuit
|
*Synthesis back end
|
output technology aware
structural circuit
|
> *Mapper
> |
output technology specific
structural circuit with specific
mapping to functional units
> |
> *PaR
> |
> output technology and physical
> details (FPGA case config stream)
>
> *indicates the FPGA eda software.
>
> If a 3rd party synthesis vendor changed their "parser" would they test
> against all possible target devices or would they simply test enough
> VHDL input test cases?
>
> I guess the Xilinx synthesis tool must incorporate device specific
> technology early on? Seems dangerous to me.
>
> Regards,
> Chris

The Mapper is not part of the synthesis tool. It is a bit like a linker
in a programming language for an MCU. The synthesis engine has a front
end that is technology independent, but also a technology aware back end
that knows the device it is compiling for because it does need to know
what functional blocks it will be mapped to.

I think some things have already been decided before it reached the
mapper. For example, whether FFs will be used for a shift register or
the SRL in a Xilinx part.

Rick

On 12/13/12 12:32 PM, rickman wrote:
> You guys need to learn to snip...
>
> On 12/12/2012 11:50 AM, Christopher Felton wrote:
>>
>> I must be missing something here, when you say parser I assume the
>> frontend of the synthesis engine? I am having a hard time seeing the
>> direct connection between the "parser" and a device. I guess if you
>> wanted to be super paranoid you could regression test against the device
>> but it seems pointless?
>>
>> The tools flow:
>>
>> input VHDL (hardware description)
>> |
> *Synthesis front end
>> |
>> output technology agnostic
>> structural circuit
> |
> *Synthesis back end
> |
> output technology aware
> structural circuit
> |
>> *Mapper
>> |
> output technology specific
> structural circuit with specific
> mapping to functional units
>> |
>> *PaR
>> |
>> output technology and physical
>> details (FPGA case config stream)
>>
>> *indicates the FPGA eda software.
>>
>> If a 3rd party synthesis vendor changed their "parser" would they test
>> against all possible target devices or would they simply test enough
>> VHDL input test cases?
>>
>> I guess the Xilinx synthesis tool must incorporate device specific
>> technology early on? Seems dangerous to me.
>>
>> Regards,
>> Chris
>
> The Mapper is not part of the synthesis tool. It is a bit like a linker
> in a programming language for an MCU.

Not sure where the confusion was but I explicitly listed synthesis, map,
P&R as separate tools. The discussion was around my surprise and
learning that the Xilinx tools are device specific from the very
beginning of their tool flow, in this case the parser. Thanks for
reiterating the point.

> The synthesis engine has a front
> end that is technology independent,

It was stated that the Xilinx parser (frontend) is *not* technology
independent!

> but also a technology aware back end
> that knows the device it is compiling for because it does need to know
> what functional blocks it will be mapped to.

I agree, generally this is true but it doesn't have to be. It just
means the *mapper* has to do more work. As your description indicates,
the syn will map and then the mapper (fitter) will map also.

>
> I think some things have already been decided before it reached the
> mapper. For example, whether FFs will be used for a shift register or
> the SRL in a Xilinx part.

Agree, but it probably depends on the flexibility and descriptability
(new word) of the intermediate format. I can't think of a reason why
the mapper couldn't perform the mapping you described (e.g. identifying
a bunch of FF as a shift-register and use the technology specific
resources).

Regards,
Chris

On 12/14/2012 11:16 AM, Christopher Felton wrote:
> On 12/13/12 12:32 PM, rickman wrote:
>> The synthesis engine has a front
>> end that is technology independent,
>
> It was stated that the Xilinx parser (frontend) is *not* technology
> independent!

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.


>> but also a technology aware back end
>> that knows the device it is compiling for because it does need to know
>> what functional blocks it will be mapped to.
>
> I agree, generally this is true but it doesn't have to be. It just means
> the *mapper* has to do more work. As your description indicates, the syn
> will map and then the mapper (fitter) will map also.

Perhaps in theory you are right, but I think they use some info in the
source to key them into intentions of the coder. This info might be
lost once the design is optimized in the synthesis back end. But I'm
not a tool writer, so I don't really know. I expect you can easily look
at a netlist and figure out some optimizations just as a C compiler can
do optimizations on the assembly language.

I do know that way back when I started using VHDL the (really crappy)
Orcad VHDL tool would barf on very small deviations from the ideal
source. But they they got out of the compiler writing business for a
reason, didn't they?


>> I think some things have already been decided before it reached the
>> mapper. For example, whether FFs will be used for a shift register or
>> the SRL in a Xilinx part.
>
> Agree, but it probably depends on the flexibility and descriptability
> (new word) of the intermediate format. I can't think of a reason why the
> mapper couldn't perform the mapping you described (e.g. identifying a
> bunch of FF as a shift-register and use the technology specific resources).

Yes, I agree. The only thing required to recognize the optimization for
an SRL would be that the FFs meet the limitations of the SRL. But what
about other, more complex features like multipliers? Wouldn't it be a
lot easier to let the synthesis tool recognize that a multiply operation
could be implemented as a primitive in the target device rather than
have the mapper recognize a multiplier implemented in LUT fabric and
swap it out? If the mapper is given a generic multiply function and
told to "figure it out", isn't that pushing synthesis into the mapping
operation? Mapping is supposed to be a limited precursor to placement
that just figures out how to map logic to the hardware such as "this LUT
can co-exist with this FF in the same CLB".

Rick

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 one is saying the
synthesis tool is not technology dependent, are they?

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?

Rick

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)
>> is begin
>> if counter = dt then
>> state <= next_state;
>> counter <= 0;
>> end if;
>> end advance_state;
>>
[...]
>> Code like this works fine when synthesized in ISE14.1 for a Spartan6
>> device, but it does not work for Spartan3.
>>
>
> There was a catastrophic known bug in ISE7,9,10,11,12 whereby signals
> passed as OUT parameters to a procedure (probably INOUT too) were
> incorrectly updated; XST used variable assignment semantics (immediate
> assignment) instead of signal assignment (postpone assignment).
>
[...]
> When I checked ISE13 I found the bug had gone; however I did not look
> carefully enough, I only tested with Spartan-6.
>
> 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!

Thomas

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

--

TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities...ronic-hardware

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/Synthesi...ew-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