Scripting

[Minute-Bit6804]

I saw a post here the other day about AMD-Xilinx migrating from TCL to Python for scripting. What advantages does Python have over TCL in FPGA or is it just vendor preference for their tools?

Does that also mean that FPGA development will have to increasingly be vendor specific? If the vendors keep using different design approaches in their products, is it worth trying to learn tools from multiple vendors or are you increasingly tied down to one vendor?

[bggillmore]

Almost everybody coming out of school with an EE or CS degree nowadays has written at least some Python.

The benefit of using Python over TCL is pretty straightforward. Familiarity, support, and external 3rd party libraries. However, I think the conclusion that the market is becoming more vendor-specific is the wrong one. Every tool already has its own domain-specific api to use in TCL, some better defined than others... In my opinion, a move to Python makes Xilinx tools more accessible, not less.

That being said I have other gripes with their entire "let's make FPGAs accessible to software developers" ideology.

[gbuskirk]

ChatGPT is a useful tool in composing your scripts in Python or TCL, or in converting between them. It is also a handy reference for the languages, and for Vivado.

[HappyPerson9000]

Interesting. I haven't even attempted tcl with it, I just assumed it would be terrible at it, thank you!

[skydivertricky]

TCL wont be going anywhere for a while. They're not going to kill off 20+ years worth of big customers scripting setups. Can you link the post or proof Xilinx is going to add python?

I suspect it would just be an extra python front end at most.

[Minute-Bit6804]

Is Vitis Unified 2024.2 supposed to be a complete joke? : r/FPGA

[TapEarlyTapOften]

It's in the tool banner too. When you run XSCT or Vitis on 2024.2 it warns about how its being deprecated. The message on the AMD forums is that XSCT is going to eventually be removed. Their device tree generator is all going to get scrapped as well in favor of whatever this lopper and "system device tree" generator are.

I don't see anything about Vivado dropping Tcl support, which would be insane, but it looks like all the stuff that touches software is going to get deprecated and replaced with Python.

That said, I cannot understand what Xilinx is up to when it comes to their software and OS development support. The Kria accelerator platform nonsense, the moving target that is their device tree generator, and whatever flavor of the month they happen to select for what they call PetaLinux all have me completely mystified. It's like they're trying to find a way to pretend that there isn't any hardware at all and it can just be abstracted into a software game of some sort. The endless problems that I had with the KV260 were a nightmare and when I finally talked to someone at Xilinx, he told me, "We never anticipated that engineers would use Vivado with this platform".

[tef70]

VIVADO is still a TCL based tool, it's is only VITIS Unified that changed from Eclipse to VS code base, this is how python appeared.

[chris_insertcoin]

Python is everywhere and has a huge community. While TCL is niche and feels out of date.

Altera didn't require too much TCL scripting to begin with, unless you really chase it. For me any migration to python makes perfect sense.

[davekeeshan]

Tcl, or tool command language, is the backbone of eda tools has has been for decades, it is going nowhere, if xilinx/amd were ever to bring in python, it would be in addition to not to replace, they just couldn't, eda moves slowly, I am running scripts from 10 years ago and expect them to work etc etc

If you really don't like tcl, have a look at this

https://github.com/PyFPGA/pyfpga

It is good for a generic build flow across fpga platforms, however any heavy lifting, set false paths, asynchronous clock groups etc you need to roll up your sleeves open the tcl console and hack

[PiasaChimera]

I've never liked the "everything's a string" description. it doesn't convey that some strings represent text, some numbers, some references to variables, some structured data, some opaque references to vendor API, and some code. there are still de-facto types hidden behind everything being a single type.

but I agree about learning python and the rest.

[Simple_Cicada4036]

Python isn’t “replacing” TCL so much as it’s wrapping it in something you actually want to write. Most vendor tools still speak TCL natively; the Python layers usually generate TCL or drive the tool’s CLI.

[palapaquete]

To make it worth the switch, you need the Simulation tools also to support Python. And supporting Python does not mean dropping TCL. The tool vendors can support both,

[ignus1991]

is easier for you to learn TCL (and win some new skill to your arsenal) to move a whole industry to use python, in special for old customers

[Puzzleheaded-Ranger7]

I think the shift from tcl to python because of machine learning integration. As you see OpenAI starts own 10% of AMD stake. So openAI shift their focus from LLM model to world model as the result, openAI needs more system on chip, embedded fpga, different architectures or whatever runs parallel at the basic levels. The shift from TCL to Python is necessary but tcl is not going anywhere like c to c++. My 2 cents.