SCons build tool as an alternative to makefiles

[Patrick Dubois]

Hello,

I have been using batch files to handle the build process with a
Xilinx flow for a while. Now I want to move to a more sophisticated
approach to handle dependencies better.

I don't really want to use makefiles, I find find them too arcane and
hard to write. That's where SCons comes in. It seems like a great
alternative to make (plus it's written in Python and I've been wanting
to learn that language for a while now).

Does anyone have any experience with SCons and ideally, scripts they
would like to share? Example scripts for a fpga flow would certainly
help with the learning curve.

Thanks.

Patrick Dubois

 

[Martin Thompson]

"Patrick Dubois" <prdubois@gmail.com> writes:

Hello,

I have been using batch files to handle the build process with a
Xilinx flow for a while. Now I want to move to a more sophisticated
approach to handle dependencies better.

This has just reminded me of something I discovered recently:

Neither PAR nor TRCE return an error if the design fails timing, so
any script/makefile which relies on the return code being non-zero as
an error (like... well... just about anything sane!) will carry on
through it's script as if everything is OK!

You have to parse the PAR logfile for "No timing errors found" if you
want to be sure.

I have a change request in to fix this, please add your weight to the
request (unless you think I'm bonkers for thinking that failing timing
is an error!)

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Patrick Dubois]

This has just reminded me of something I discovered recently:

Neither PAR nor TRCE return an error if the design fails timing, so
any script/makefile which relies on the return code being non-zero as
an error (like... well... just about anything sane!) will carry on
through it's script as if everything is OK!

You have to parse the PAR logfile for "No timing errors found" if you
want to be sure.

I have a change request in to fix this, please add your weight to the
request (unless you think I'm bonkers for thinking that failing timing
is an error!)

Cheers,
Martin

Very good point. I always try to remind new engineers here to always
remember to check the timing report part of the PAR log to make sure
that there are no timing errors. I'll try to open a webcase on the
issue. Do you have a CR number I can refer to?

Patrick

 

[Martin Thompson]

"Patrick Dubois" <prdubois@gmail.com> writes:

This has just reminded me of something I discovered recently:

Neither PAR nor TRCE return an error if the design fails timing, so
any script/makefile which relies on the return code being non-zero as
an error (like... well... just about anything sane!) will carry on
through it's script as if everything is OK!

You have to parse the PAR logfile for "No timing errors found" if you
want to be sure.

I have a change request in to fix this, please add your weight to the
request (unless you think I'm bonkers for thinking that failing timing
is an error!)

Cheers,
Martin

Very good point. I always try to remind new engineers here to always
remember to check the timing report part of the PAR log to make sure
that there are no timing errors. I'll try to open a webcase on the
issue. Do you have a CR number I can refer to?

Not yet, I'll try and remember to post it here when I get it...

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

A long time ago we were bitten by this, and we added this to our
Makefile to check
that PAR met timing:

#
# Place and route the mapped netlist into the device
#
%_routed.ncd: %.ncd
par -w $(PAR_FLAGS) $< $@
@grep 'All constraints were met' $*_routed.par > /dev/null ||
false

Granted, it relies on Xilinx not changin the wording of the 'All
constraints...' line.

cheers,
aaron

On Mar 2, 8:56 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

"Patrick Dubois" <prdub...@gmail.com> writes:
This has just reminded me of something I discovered recently:

Neither PAR nor TRCE return an error if the design fails timing, so
any script/makefile which relies on the return code being non-zero as
an error (like... well... just about anything sane!) will carry on
through it's script as if everything is OK!

You have to parse the PAR logfile for "No timing errors found" if you
want to be sure.

I have a change request in to fix this, please add your weight to the
request (unless you think I'm bonkers for thinking that failing timing
is an error!)

Cheers,
Martin

Very good point. I always try to remind new engineers here to always
remember to check the timing report part of the PAR log to make sure
that there are no timing errors. I'll try to open a webcase on the
issue. Do you have a CR number I can refer to?

Not yet, I'll try and remember to post it here when I get it...

Cheers,
Martin

--
martin.j.thomp...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html

 

[Jim Wu]

On Mar 1, 7:03 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

"Patrick Dubois" <prdub...@gmail.com> writes:
Hello,

I have been using batch files to handle the build process with a
Xilinx flow for a while. Now I want to move to a more sophisticated
approach to handle dependencies better.

This has just reminded me of something I discovered recently:

Neither PAR nor TRCE return an error if the design fails timing, so
any script/makefile which relies on the return code being non-zero as
an error (like... well... just about anything sane!) will carry on
through it's script as if everything is OK!

You have to parse the PAR logfile for "No timing errors found" if you
want to be sure.

I have a change request in to fix this, please add your weight to the
request (unless you think I'm bonkers for thinking that failing timing
is an error!)

Failing timing is an error, but personally I don't want the tool to
return an error code just because of timing errors:
* I have seen people over-constraining designs. If par doesn't meet
the over-constrained timing but meets the desired timing, I don't want
my script to stop.
* If I am in the lab debugging my design and want to quickly try out a
few things, I don't want my script to stop just because one net failed
timing by several ps.

Cheers,
Jim
http://home.comcast.net/~jimwu88/tools/

 

[Martin Thompson]

Martin Thompson <martin.j.thompson@trw.com> writes:

I remembered

CR # 435345

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Martin Thompson]

"Jim Wu" <jimwu88NOOOSPAM@yahoo.com> writes:

On Mar 1, 7:03 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
"Patrick Dubois" <prdub...@gmail.com> writes:
Hello,

I have been using batch files to handle the build process with a
Xilinx flow for a while. Now I want to move to a more sophisticated
approach to handle dependencies better.

This has just reminded me of something I discovered recently:

Neither PAR nor TRCE return an error if the design fails timing, so
any script/makefile which relies on the return code being non-zero as
an error (like... well... just about anything sane!) will carry on
through it's script as if everything is OK!

You have to parse the PAR logfile for "No timing errors found" if you
want to be sure.

I have a change request in to fix this, please add your weight to the
request (unless you think I'm bonkers for thinking that failing timing
is an error!)

Failing timing is an error, but personally I don't want the tool to
return an error code just because of timing errors:

OK< I can see people want to work in different ways, but to have the
*default* situation of "no error on error" is counter-intuitive!

* I have seen people over-constraining designs. If par doesn't meet
the over-constrained timing but meets the desired timing, I don't want
my script to stop.

I do Why overconstrain? If they want some margin on the design,
are they be happy with less margin than you asked for?

* If I am in the lab debugging my design and want to quickly try out a
few things, I don't want my script to stop just because one net failed
timing by several ps.

Maybe, that's why one of my suggestions to Xilinx is that they return
the timing score, so you can decide how much failure is acceptable
(from "0" upwards).

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Patrick Dubois]

Just to come back on the subject of Scons for a minute... Any input on
that tool? Or does anyone have another suggestion for a make
alternative?

Thanks.

Patrick

 

[Martin Thompson]

"Patrick Dubois" <prdubois@gmail.com> writes:

Just to come back on the subject of Scons for a minute... Any input on
that tool?

It does look neat, but will require some work to make it do what we
want I imagine...

It also seems to be solving a more difficult problem that FPGA
building, which seems (to me) to be a fairly linear series of events
where the only dependency is on the previous process.

Or does anyone have another suggestion for a make
alternative?

Why do you dislike make?

Personally, I just use a series of batch files...

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Jim Wu]

On Mar 5, 3:51 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

"Jim Wu" <jimwu88NOOOS...@yahoo.com> writes:
On Mar 1, 7:03 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
"Patrick Dubois" <prdub...@gmail.com> writes:
Hello,

I have been using batch files to handle the build process with a
Xilinx flow for a while. Now I want to move to a more sophisticated
approach to handle dependencies better.

This has just reminded me of something I discovered recently:

Neither PAR nor TRCE return an error if the design fails timing, so
any script/makefile which relies on the return code being non-zero as
an error (like... well... just about anything sane!) will carry on
through it's script as if everything is OK!

You have to parse the PAR logfile for "No timing errors found" if you
want to be sure.

I have a change request in to fix this, please add your weight to the
request (unless you think I'm bonkers for thinking that failing timing
is an error!)

Failing timing is an error, but personally I don't want the tool to
return an error code just because of timing errors:

OK< I can see people want to work in different ways, but to have the
*default* situation of "no error on error" is counter-intuitive!

* I have seen people over-constraining designs. If par doesn't meet
the over-constrained timing but meets the desired timing, I don't want
my script to stop.

I do Why overconstrain? If they want some margin on the design,
are they be happy with less margin than you asked for?

Some people overconstrain designs to get more margin. Some do it just
to get the design to meet the target frequency. (e.g. if my design
needs to run at 100Mhz and it never meets the timing if I put a 10ns
period constraint. If I put a 9ns period constraint, the design
doesn't meet the 9ns timing, however if it shows the design can run at
9.7ns period, I am happy.). I am NOT suggesting people overconstrain
their designs though as it may hurt the timing result as well..

* If I am in the lab debugging my design and want to quickly try out a
few things, I don't want my script to stop just because one net failed
timing by several ps.

Maybe, that's why one of my suggestions to Xilinx is that they return
the timing score, so you can decide how much failure is acceptable
(from "0" upwards).

I use Makefile most of time. A return value of non-zero will cause
make to exit unless I put some checking into my Makefile. Your
suggestion solves one problem, but creates another. Grepping timing
score from the par report is pretty easy, so why bother to change the
behavior of the tool, which would make "make" users unhappy.

Cheers,
Jim
http://home.comcast.net/~jimwu88/tools/

 

[Patrick Dubois]

Why do you dislike make?

Personally, I just use a series of batch files...

Cheers,
Martin

I don't like make mainly because of its obscure "language" and because
I found it very hard to debug a makefile. Granted, I'm no expert on
makefiles and that might be why I have trouble with it but others
seems to agree:
http://freshmeat.net/articles/view/1702/

Now the reason I'm looking for something more powerful than batch
files is because my project is modular. I compile most modules (10 at
the moment) into its own separate ngc file that I combine together
later in the flow. Compiling all these modules each time takes too
much time (which is why I separated them in the first place).

Right now I just keep track mentally of which file I changed and
rebuild the corresponding module manually (by launching its batch
file). I would prefer a tool that keep tracks of file changes
automatically and rebuilds only the modules that are necessary, which
is what Make or SCons could do for me.

Thanks for you interest.

Patrick

 

[Martin Thompson]

"Jim Wu" <jimwu88NOOOSPAM@yahoo.com> writes:

I use Makefile most of time. A return value of non-zero will cause
make to exit unless I put some checking into my Makefile. Your
suggestion solves one problem, but creates another. Grepping timing
score from the par report is pretty easy, so why bother to change the
behavior of the tool, which would make "make" users unhappy.

It will make new users happy. They expect an error to be an error,
surely?

Anyway, I think we'll end up with a command-line switch to keep us all
happy! Actually we'll probably end up with that typical Xilinx
solution of an environment variable kludge..

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Martin Thompson]

"Patrick Dubois" <prdubois@gmail.com> writes:

Why do you dislike make?

Personally, I just use a series of batch files...

Cheers,
Martin

I don't like make mainly because of its obscure "language" and because
I found it very hard to debug a makefile. Granted, I'm no expert on
makefiles and that might be why I have trouble with it but others
seems to agree:
http://freshmeat.net/articles/view/1702/

Fair enough.

Now the reason I'm looking for something more powerful than batch
files is because my project is modular. I compile most modules (10 at
the moment) into its own separate ngc file that I combine together
later in the flow. Compiling all these modules each time takes too
much time (which is why I separated them in the first place).

Ahh, yes I can see that being a problem! In that case, SCons looks
like it could be a good route, it certainly looks a lot more flexible
than make, but it may have a bigger learning curve (!)

Right now I just keep track mentally of which file I changed and
rebuild the corresponding module manually (by launching its batch
file). I would prefer a tool that keep tracks of file changes
automatically and rebuilds only the modules that are necessary, which
is what Make or SCons could do for me.

What source language are you using? I can see that it might be tricky
to teach SCons how to deal with VHDL, given that entities and archs
are unrealted by name to the file they exist in. Finding C
dependencies by header file name is a little easier!

But Make will be no easier!

If using VHDL, maybe you could create a Compiler target for Emacs'
vhdl-mode that runs XST (for example) instead of Modelsim's vcom etc.

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Patrick Dubois]

Ahh, yes I can see that being a problem! In that case, SCons looks
like it could be a good route, it certainly looks a lot more flexible
than make, but it may have a bigger learning curve (!)

At least by learning SCons I'll be learning some Python (hopefully) as
well.

What source language are you using? I can see that it might be tricky
to teach SCons how to deal with VHDL, given that entities and archs
are unrealted by name to the file they exist in. Finding C
dependencies by header file name is a little easier!

But Make will be no easier!

I'm using VHDL. If I could make SCons smart enough to figure out
dependencies automatically that would be nice but I'm not looking for
something that smart. Actually I don't want something that smart. I
want complete control over source files dependencies, even if that
means that I must specify them explicitly myself.

If using VHDL, maybe you could create a Compiler target for Emacs'
vhdl-mode that runs XST (for example) instead of Modelsim's vcom etc.

I keep hearing about Emacs vhdl-mode but I'm not using it at the
moment. I might give it a try when I have more spare time. Thanks for
the suggestion.

Regards,
Patrick

 

[Martin Thompson]

"Patrick Dubois" <prdubois@gmail.com> writes:

Ahh, yes I can see that being a problem! In that case, SCons looks
like it could be a good route, it certainly looks a lot more flexible
than make, but it may have a bigger learning curve (!)

At least by learning SCons I'll be learning some Python (hopefully) as
well.

And then you can use MyHDL for your logic

What source language are you using? I can see that it might be tricky
to teach SCons how to deal with VHDL, given that entities and archs
are unrealted by name to the file they exist in. Finding C
dependencies by header file name is a little easier!

But Make will be no easier!

I'm using VHDL. If I could make SCons smart enough to figure out
dependencies automatically that would be nice but I'm not looking for
something that smart. Actually I don't want something that smart. I
want complete control over source files dependencies, even if that
means that I must specify them explicitly myself.

OK, that'll make life easier I imagine.

If using VHDL, maybe you could create a Compiler target for Emacs'
vhdl-mode that runs XST (for example) instead of Modelsim's vcom etc.

I keep hearing about Emacs vhdl-mode but I'm not using it at the
moment. I might give it a try when I have more spare time. Thanks for
the suggestion.

Well worth the effort IMHO!

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Eric Anderson]

On Mon, 20 Aug 2007 13:49:01 +0000, young wrote:

"Patrick Dubois" <prdub...@gmail.com> writes:

Just to come back on the subject of Scons for a minute... Any input on
that tool? Or does anyone have another suggestion for a make
alternative?


In a very-belated follow up:

I've been using SCons for building projects in Xilinx ISE (12.2), and
I
find it to be pretty suitable. Tasks like extracting build options
and
dependencies from project files are quite manageable, at least with
the
newer XML-based .xise files.

I've uploaded an example SConstruct on Github here:
https://github.com/ewa/xilinx-build-scripts . I'd love to see people
use
and improve it.

Cheers,
Eric

 

[Christopher Felton]

On 4/4/2011 5:51 PM, Eric Anderson wrote:

On Mon, 20 Aug 2007 13:49:01 +0000, young wrote:

"Patrick Dubois"<prdub...@gmail.com> writes:
Just to come back on the subject of Scons for a minute... Any input on
that tool? Or does anyone have another suggestion for a make
alternative?


In a very-belated follow up:

I've been using SCons for building projects in Xilinx ISE (12.2), and
I
find it to be pretty suitable. Tasks like extracting build options
and
dependencies from project files are quite manageable, at least with
the
newer XML-based .xise files.

I've uploaded an example SConstruct on Github here:
https://github.com/ewa/xilinx-build-scripts . I'd love to see people
use
and improve it.

Cheers,
Eric
Thanks for sharing, I have not looked at your files yet but did you use

a customer "builder"? And if so, can it be tailored for other FPGA tools.

Thanks
Chris