SCons build tool as an alternative to makefiles

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

Reply to
Patrick Dubois
Loading thread data ...

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
 Click to see the full signature
Reply to
Martin Thompson

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

Reply to
Patrick Dubois

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
 Click to see the full signature
Reply to
Martin Thompson

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, aar> "Patrick Dubois" writes:

Technology

formatting link

Reply to
aholtzma

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

formatting link

Reply to
Jim Wu

I remembered :-)

CR # 435345

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
 Click to see the full signature
Reply to
Martin Thompson

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 do :-) Why overconstrain? If they want some margin on the design, are they be happy with less margin than you asked for?

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
 Click to see the full signature
Reply to
Martin Thompson

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

Reply to
Patrick Dubois

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.

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
 Click to see the full signature
Reply to
Martin Thompson

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

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

formatting link

Reply to
Jim Wu

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:

formatting link

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

Reply to
Patrick Dubois

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
 Click to see the full signature
Reply to
Martin Thompson

Fair enough.

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 (!)

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
 Click to see the full signature
Reply to
Martin Thompson

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

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.

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

Reply to
Patrick Dubois

And then you can use MyHDL for your logic :-)

OK, that'll make life easier I imagine.

Well worth the effort IMHO!

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
 Click to see the full signature
Reply to
Martin Thompson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.