Author Topic: WTF Xilinx  (Read 22631 times)

0 Members and 4 Guests are viewing this topic.

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6710
  • Country: fi
    • My home page and email address
Re: WTF Xilinx
« Reply #100 on: June 14, 2020, 01:18:51 pm »
Your script simply extends the capabilities of the GUI. It doesn't change the principle.

It's not "my script", it's how EagleCad, Wildifire, Maya, and a lot of tools do thier job.

And I have never written it has to change the principle.
But I did, kinda sorta:  it is a different approach.  That's the key point here.

Lets compare OpenSCAD to say Fusion 360.  Fusion 360 lets you parametrically define the features of the objects, and create objects parametrically.  OpenSCAD generates objects and collections of objects using a simple language based on solid geometry; the language isn't even procedural, although it has loops and such.  For individual features or sub-objects, you can create modules.

What's the difference, then?

In one, if you find your commands or script didn't do what you wanted, you delete and rewrite it.
In the other, you simply modify part of the description of the modeled system.

The same difference exists between SVG and other vector formats used on the web, like web fonts.  SVG is verbose and human-readable, but it is also modifiable in real time by Javascript on the web page; not so for web fonts.

The core difference I am trying to convey here, is that in EagleCAD etc., the scriptlets produce objects as if they were created by hand in the GUI.  If you rerun the scriptlet, you get another object.  The scriptlets are essentially macros for human GUI actions played back at amazing speed.
In OpenSCAD and NorthGuys PCB program, the script actively describes the objects; by modifying the script, you modify the object.

Why isn't the latter implemented in GUI-based tools?

Because it is rarely possible to translate the human actions via the GUI back to the underlying script describing the objects.

It is possible for 2D (demonstrably; Inkscape does it that way, and even allows you to modify the source by hand during editing), and it is possible for solid geometry in general, but usually the "human by hand" and "generated via GUI" are very different, for a number of reasons.

(As an example, even Inkscape has a "Save as Optimized SVG" mode, which more closely resembles how humans and efficient scripts generate SVG code, but the end result lacks many of the niceties of the default/GUI-generated objects, like rotation centres, often layers, and so on.  I personally tend to even fine-tune that further. And it isn't hard to crash Inkscape by careless modification of the underlying XML code either.)

This means that a tool which used an underlying domain-specific descriptive language exposed for user editing to describe the work at hand, but allows simultaneous modification to the underlying language by hand and via the GUI, is going to have to make compromises that make no sense to users that use predominantly one approach over the other.

That does not mean one is superior to the other: it depends on how the tool is used.  The root principle, or paradigm.

You well know the idiom "if all you have is a hammer, all problems look like nails."  As I've already told you, asking dozens of "house frame-builders" (who predominantly use a hammer and a saw to make the wooden frame, in this analog), you for sure get the answer that screwdrivers and industrial adhesives are meh because a hammer does the job much faster and easier.  OpenSCAD in particular solves a different problem than Fusion 360: it lets one describe the object needed via solid geometry, and it'll show you how it looks like; whereas Fusion 360 lets you design any object with set constrains that you can imagine.

While designing a PCB is seemingly a single problem, NorthGuy has already mentioned they wouldn't use their own tool for analog designs; and rather created it to simplify working with a specific type of digital circuit (to simplify, lots of pins and simple traces).  If you think about it, that actually makes sense to describe using a simple language.

A good example is a circuit I've been playing with recently: a simple Arduino-programmable display module accelerator.  An ARM microcontroller in QFP64/LQFP64 package with 22 or so pins connected to a display module, and the rest of the I/O pins exposed as a pin header, with a crystal/resonator, bypass capacitors, and maybe a 5V-to-3.3V LDO or DC-DC converter on the board.
There are 16 orientations for the microcontroller with respect to the display module flex connector pins: 4 aligned and 4 diagonal on the same side of the board, and 4 aligned and 4 diagonal on the other side of the board.  The flex connector pins are basically the only thing fixed on the board, everything else is up to me.

To be honest, I'm very tempted to write a simple Python program to investigate those 16 orientations, to find out how many trace crossings each one involves, and whether there is a simple two-layer solution – i.e., to qualify each of the 16 orientations before I really start looking into how to draw the traces.  It is easier for me than trying to do all 16 in an EDA, or even to just pick one and work it through even if it is sub-optimal.

When I know which one has least problems, I'll be quite happy to use any GUI EDA tool – I like EasyEda – to design the actual board.

(Also, I know that if someone has read this far, they have ideas on how to accomplish this using their own favourite tools.  That is perfectly okay, but it is important to realize that having a favourite tool does not make it optimal.  And just like there are *lots* of say woodworkers using only hand tools, it is perfectly okay to use the tools you like; but it isn't okay to use that as a basis for claiming there is no need for any other kinds of tools, or even that you can do everything those other tools can do with your own favourite ones, because the underlying preference is dependent on personal features and varies from individual to individual.  It is, however, perfectly okay to tell how oneself likes to do those things using their own preferred tools, because that can give others new ideas without asserting a comparison between tools, and we all stand to gain.)
« Last Edit: June 14, 2020, 01:23:19 pm by Nominal Animal »
 
The following users thanked this post: 0db

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3237
  • Country: ca
Re: WTF Xilinx
« Reply #101 on: June 14, 2020, 02:31:39 pm »
You well know the idiom "if all you have is a hammer, all problems look like nails."

I'm a programmer. Everything looks like a program to me :)
 
The following users thanked this post: coldfiremc

Offline coldfiremc

  • Regular Contributor
  • *
  • Posts: 75
  • Country: cl
Re: WTF Xilinx
« Reply #102 on: August 11, 2022, 02:16:45 pm »
In This thread we figured out what stuff is bloating Vivado. Pls check

https://support.xilinx.com/s/question/0D52E00006hpOUpSAM/vivado-installation-is-at-least-14-gb-too-large?language=en_US


Also don't forget to make more noise commenting or giving some likes. The installer is flawed, just that

 

Offline coldfiremc

  • Regular Contributor
  • *
  • Posts: 75
  • Country: cl
Re: WTF Xilinx
« Reply #103 on: August 11, 2022, 02:18:50 pm »
Vivado is not slow because of tcl or scripting languages, is just slow because the implementation is crappy. The IDE just talks to the console polling files. Also, the console talks to executables just using a pipe. Is kind of primitive. A better approach would be to make binary executables as modules, like in Xcircuit
« Last Edit: August 11, 2022, 08:07:31 pm by coldfiremc »
 

Offline pbernardi

  • Contributor
  • Posts: 19
  • Country: br
Re: WTF Xilinx
« Reply #104 on: August 11, 2022, 07:03:01 pm »
Last time I dared to download a recent Vivado version, it lasted around one hour in my computer before I uninstall it. Really useless stuff: big, slow, unusable.  |O

I am amazed of how good are older software compared to newer versions. I use Vivado 2018.3, but only because it has support to the FPGA family I use, and personally think ISE 14.7 was much better in general. With Vivado, I learned that I must not, in any case, ever, try to use the embedded text editor because it simply does not work for real codes. Once I realized this, my life changed and I could smile again, and since then I find Vivado 2018.3 a palatable software.

And this happens not only for Vivado or Xilinx, for most software available. When I want to use some stuff without restrictions, ads or even when I want a better software I just look for older versions. I am almost never disappointed.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15094
  • Country: fr
Re: WTF Xilinx
« Reply #105 on: August 11, 2022, 07:08:05 pm »
This is often the case indeed, but not always. Lattice tools are IMO an exception. Both Diamond and Radiant are simple, unbloated (relatively...) and fast. Newer versions tend to be better rather than worse. Now this may change, if, like others, Lattice suddenly decides to rewrite Diamond with a brand new team and brand new language, but I don't think it's gonna happen anytime soon. They seem to be focusing on Radiant for their newer parts, Radiant is still relatively "new" (so I doubt they're gonna rewrite it completely for many years to come) and was a decently good surprise when they released it.

Of course none of these two are as complex or as featureful as Vivado, though. Lattice tends to use a different path - standalone applications for special features, instead of cramming it all in a single one.
 

Offline coldfiremc

  • Regular Contributor
  • *
  • Posts: 75
  • Country: cl
Re: WTF Xilinx
« Reply #106 on: August 11, 2022, 07:20:26 pm »
If you turn off sigasi Syntax checking, goes way better
 

Offline pbernardi

  • Contributor
  • Posts: 19
  • Country: br
Re: WTF Xilinx
« Reply #107 on: August 11, 2022, 07:38:03 pm »
If you turn off sigasi Syntax checking, goes way better

That´s true. However, then I need to check logs or files to look for errors.

And if I need to do this, what is the benefice of using the Vivado text editor? I mean, I have to disable the only useful feature because it turns my job is painfully slow. Better to use any other IDE instead.
 

Offline coldfiremc

  • Regular Contributor
  • *
  • Posts: 75
  • Country: cl
Re: WTF Xilinx
« Reply #108 on: August 11, 2022, 08:09:01 pm »
If you turn off sigasi Syntax checking, goes way better

That´s true. However, then I need to check logs or files to look for errors.

And if I need to do this, what is the benefice of using the Vivado text editor? I mean, I have to disable the only useful feature because it turns my job is painfully slow. Better to use any other IDE instead.

You can use check_syntax from tcl console. Is faster than elaborate
 

Offline coldfiremc

  • Regular Contributor
  • *
  • Posts: 75
  • Country: cl
Re: WTF Xilinx
« Reply #109 on: August 11, 2022, 08:09:58 pm »
Last time I dared to download a recent Vivado version, it lasted around one hour in my computer before I uninstall it. Really useless stuff: big, slow, unusable.  |O

I am amazed of how good are older software compared to newer versions. I use Vivado 2018.3, but only because it has support to the FPGA family I use, and personally think ISE 14.7 was much better in general. With Vivado, I learned that I must not, in any case, ever, try to use the embedded text editor because it simply does not work for real codes. Once I realized this, my life changed and I could smile again, and since then I find Vivado 2018.3 a palatable software.

And this happens not only for Vivado or Xilinx, for most software available. When I want to use some stuff without restrictions, ads or even when I want a better software I just look for older versions. I am almost never disappointed.

2021 is way faster than 2018/2019, but sigasi by default on is not helping to make it shine
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf