procedure problem

[Thomas Heller]

I have a statemachine that needs to maintain each current state for a
certain time, then switch to another state.
To save tedious typing, I wrote a helper procedure that I call
with
- the state signal instance,
- the next state value,
- the counter signal instance which is used to count the remaining
clock cycles,
- and the number of clock cycles to wait.

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;

and here a snippet of the state machine code:

process(clock)
begin
if rising_edge(clock) then
case state is
when IDLE =>
if we = '1' then
state <= START_A;
counter <= 0;
end if;

when START_A => advance_state(state, START_B, counter, 2000);
....
when START_B => advance_state(state, START_C, counter, 2000);
....
when START_C => advance_state(state, WRITE_A, counter, 2000);
....

Code like this works fine when synthesized in ISE14.1 for a Spartan6
device, but it does not work for Spartan3.

Does anyone see a problem with the above?
Are there better ways to implement a state machine with state-duration?

Thanks,
Thomas

 

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

Where do you increment the counter?

-- Pontus

 

[Thomas Heller]

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

 

[Christopher Felton]

Am 11.12.2012 16:33, schrieb Pontus:

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.


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.

Chris

 

[Thomas Heller]

Am 11.12.2012 17:53, schrieb Christopher Felton:

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.

How do others write statemachines with certain durations for the states?

Thomas

 

[Christopher Felton]

Am 11.12.2012 17:53, schrieb Christopher Felton:

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

 

[Gabor]

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.


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

 

[KJ]

On Tuesday, December 11, 2012 9:52:41 AM UTC-5, Thomas Heller wrote:

- The state machine has no reset. There is nothing to get it into a valid state which then can be stepped through once reset completes. That alone would cause it to work in simulation but not always work in actual hardware.

- Signal state is an output only of the procedure. That shouldn't matter for the problem you're seeing (which is not clear what exactly is the problem...you didn't say).

- Since you asked, I would've written it like this...

if rising_edge(clock) then
if (reset = '1') then
state <= idle; -- I presume
counter = 0;
elsif (counter = dt) then
counter = 0;
case state is
when START_A => state <= START_B;
...
end case;
else
counter <= counter + 1;
end if;
end if;

Not that what you have is wrong, but you asked how others would write it that are 'better'. Whether you think yours is better or not is up to you based on your own criteria.

Kevin Jennings

 

[Christopher Felton]

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

 

[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

 

[Christopher Felton]

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

 

[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

 

[rickman]

You guys need to learn to snip...

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

 

[Christopher Felton]

You guys need to learn to snip...


|
*Synthesis back end
|
output technology aware
structural circuit
|
output technology specific
structural circuit with specific
mapping to functional units

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

 

[rickman]

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.

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?

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

 

[rickman]

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

 

[Thomas Heller]

Am 15.12.2012 11:20, schrieb Brian Drummond:

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

 

[Martin Thompson]

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

 

[rickman]

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.

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