5 ms·

The best part of open-source synthesis tools is that they don't require absurdly bloated development environments. The only thing I've encountered that's worse

The best part of open-source synthesis tools is that they don't require absurdly bloated development environments. The only thing I've encountered that's worse is Android Studio. Getting more efficient output is a nice bonus.

SuperMouse 1y ago
Most FPGA vendor tools can be used from the console. But they are very fat.
- polalavik 1y ago
  I know of a few vendor tools whose application size is measured in the multi-hundred of GBs
  - SuperMouse 1y ago
    Xilinx and Altera want to talk to you :-)
    - deleted 1y ago
      [deleted]
  - topspin 1y ago
    How does that happen? When I see this, I suspect the vendor is operating under conditions that approach absolute chaos: dumping whatever junk someone imagines might be necessary into the stack with zero resistance, for years on end. Zero effort spent on any factoring that might threaten redundancy.
    - adwn 1y ago
      Xilinx toolchain installations used to include a file which was just the concatenation of the license files of every single open source library they were using somewhere inside any of their own software. Now if you installed two or more components of their toolchain (for example, Vivado, Vitis, and PetaLinux) into the shared installation directory, this same file was installed several times as well. Together, they made up something like 1.5 GiB alone. I think they've fixed this only a year ago or so.
      - ithkuil 1y ago
        Seems a good candidate for a file that can be kept in a compressed form
    - mschuster91 1y ago
      Welcome to modern development lol. Try to refactor it and get an answer of "no money for testing". On top of that, the "agile" mindset all too often also means there is no coherent vision where the project should go, which can and does lead to bad fundamental architecture decisions that need extensive and expensive workarounds later on. And yes, there have been people describing exactly that in ASML [1], although the situation seems to have improved [2]. [1] https://news.ycombinator.com/item?id=23363938 https://news.ycombinator.com/item?id=23363938 [2] https://news.ycombinator.com/item?id=39465412 https://news.ycombinator.com/item?id=39465412
    - RossBencina 1y ago
      I'm not saying the tools aren't bloated, but I believe that a lot of the size (sorry, can't quantify right now) are the datasets for each and every FPGA model that the tool supports. This includes, among other things, timing information for every wire in the chip. You really only need the files for the device that you are targeting and you do have the option to install only that, or you can install larger groups (e.g. same family, same generation), all the way up to installing every device that ever existed that the tool supports. That's how you get to hundreds of GB.
      - goku12 1y ago
        Are you sure about that, or is it just a guess? If that is the case, how will the open source toolchains avoid the same problem when they eventually become the industry standard? (I can imagine something like a software repository for serving device-specific information on demand.) Are they planning anything right now?
st_goliath 1y ago
> ... don't require absurdly bloated development environments. Outside hobbies, I've been mostly away from this field for little over a decade by now. Is it still that bad? I remember back then, every single professional electronics engineer that I met had this die hard belief that this was simply how things work: You want to use DerpSemi micro controllers? You must install DerpStudio '98! Not the later 2005 version tough, that has some major UI bugs. You want to program a HerpSoft PLC? You need EasyHerpes IDE! What, command line toolchain? Text editor? You must be completely insane! It's been somewhat of a personal fight against windmills for me back then. That, plus suggesting that we are actually developing software and the C/Assembly/VHDL maybe shouldn't be an undocumented, tested-only-once pile of spaghetti based off a circuit diagram inside one guys head (and no, a 50 line comment block with a German transcription of the code below is not documentation).
- robinsonb5 1y ago
  One thing I will say in favour of the Gowin IDE - it does seem to be much more lightweight than the larger vendors' tools. For smaller designs it will often go from zero to bitstream in less time than Quartus or Vivado would have taken to even start synthesizing.
- Ygg2 1y ago
  > and no, a 50 line comment block with a German transcription of the code below is not documentation You had it good back then. Now it's a one-line comment in Chinese. Line is 300 characters wide. /Yorkshire men skit.
  - st_goliath 1y ago
    Now that's funny. The irony here is that, besides German (native), I do speak some HSK4-ish Mandarin as a 3rd language. A few years ago, a single line Chinese comment next to a blob of magic hex values did help me figure out a bug in a touch controller driver :-)
- wucke13 1y ago
  I have dedicated a large chunk of my (arguably short) professional career on improving upon this, mostly in the safety critical software domain. What was your experience back then, what made you leave ultimately, and what do you do now?
adwn 1y ago
As much as I wish this would come true, there's little chance for a full, end-to-end open source toolchain for Xilinx or Altera FPGAs that's competitive with the vendor tools. The reason for this is that there's no publicly available documentation of the signal routing configuration or the bitstream format, which are required for the final two steps in the chain. I don't see the two market leaders releasing this information anytime soon, and reverse engineering it from the data files is probably rather difficult. The synthesis discussed in the linked page is one of the earliest steps, and from the point of view of open source implementations, the simplest one, because all necessary information is freely available.
- aappleby 1y ago
  "there's no publicly available documentation of the signal routing configuration or the bitstream format" Both of things either have already been reverse-engineered, or are in the process of being reverse-engineered.
  - robinsonb5 1y ago
    The reverse engineering efforts are impressive (though as I understand it, limited to Xilinx series 7 and Cyclone V) but without robust and reliable timing data to go with the rest of the chip data, they can't give you the same level of confidence that a design will work across a range of a devices and operating conditions.
    - amirhirsch 1y ago
      For the curious: the process of discovering the logic and route timings for an FPGA device is to use ring oscillators (three series inverters) and compare counters against a known clock. Place the inverters all over to test every LUT, and use every routing path to test each path's timing.
  - adwn 1y ago
    > Both of things either have already been reverse-engineered, or are in the process of being reverse-engineered. Please provide a source for this claim. Yosys, for example, can't route [1] designs even for Xilinx 7-series devices, and that architecture has been introduced 15 years ago. [1] Not to be confused with synthesis, mapping, or placing, all of which come earlier in the flow, and for all of which sufficient information is public available.
tverbeure 1y ago
The installation can be around 100GB, which is a lot, but you have to distinguish the build part from the IDE. I hardly ever use the IDE and just use a Makefile. The open source tools still lack too many features to be useful for non-hobby development.

SuperMouse 1y ago

Most FPGA vendor tools can be used from the console. But they are very fat.

polalavik 1y ago
I know of a few vendor tools whose application size is measured in the multi-hundred of GBs
- SuperMouse 1y ago
  Xilinx and Altera want to talk to you :-)
  - deleted 1y ago
    [deleted]
- topspin 1y ago
  How does that happen? When I see this, I suspect the vendor is operating under conditions that approach absolute chaos: dumping whatever junk someone imagines might be necessary into the stack with zero resistance, for years on end. Zero effort spent on any factoring that might threaten redundancy.
  - adwn 1y ago
    Xilinx toolchain installations used to include a file which was just the concatenation of the license files of every single open source library they were using somewhere inside any of their own software. Now if you installed two or more components of their toolchain (for example, Vivado, Vitis, and PetaLinux) into the shared installation directory, this same file was installed several times as well. Together, they made up something like 1.5 GiB alone. I think they've fixed this only a year ago or so.
    - ithkuil 1y ago
      Seems a good candidate for a file that can be kept in a compressed form
  - mschuster91 1y ago
    Welcome to modern development lol. Try to refactor it and get an answer of "no money for testing". On top of that, the "agile" mindset all too often also means there is no coherent vision where the project should go, which can and does lead to bad fundamental architecture decisions that need extensive and expensive workarounds later on. And yes, there have been people describing exactly that in ASML [1], although the situation seems to have improved [2]. [1] https://news.ycombinator.com/item?id=23363938 https://news.ycombinator.com/item?id=23363938 [2] https://news.ycombinator.com/item?id=39465412 https://news.ycombinator.com/item?id=39465412
  - RossBencina 1y ago
    I'm not saying the tools aren't bloated, but I believe that a lot of the size (sorry, can't quantify right now) are the datasets for each and every FPGA model that the tool supports. This includes, among other things, timing information for every wire in the chip. You really only need the files for the device that you are targeting and you do have the option to install only that, or you can install larger groups (e.g. same family, same generation), all the way up to installing every device that ever existed that the tool supports. That's how you get to hundreds of GB.
    - goku12 1y ago
      Are you sure about that, or is it just a guess? If that is the case, how will the open source toolchains avoid the same problem when they eventually become the industry standard? (I can imagine something like a software repository for serving device-specific information on demand.) Are they planning anything right now?

st_goliath 1y ago

> ... don't require absurdly bloated development environments. Outside hobbies, I've been mostly away from this field for little over a decade by now. Is it still that bad? I remember back then, every single professional electronics engineer that I met had this die hard belief that this was simply how things work: You want to use DerpSemi micro controllers? You must install DerpStudio '98! Not the later 2005 version tough, that has some major UI bugs. You want to program a HerpSoft PLC? You need EasyHerpes IDE! What, command line toolchain? Text editor? You must be completely insane! It's been somewhat of a personal fight against windmills for me back then. That, plus suggesting that we are actually developing software and the C/Assembly/VHDL maybe shouldn't be an undocumented, tested-only-once pile of spaghetti based off a circuit diagram inside one guys head (and no, a 50 line comment block with a German transcription of the code below is not documentation).

robinsonb5 1y ago
One thing I will say in favour of the Gowin IDE - it does seem to be much more lightweight than the larger vendors' tools. For smaller designs it will often go from zero to bitstream in less time than Quartus or Vivado would have taken to even start synthesizing.
Ygg2 1y ago
> and no, a 50 line comment block with a German transcription of the code below is not documentation You had it good back then. Now it's a one-line comment in Chinese. Line is 300 characters wide. /Yorkshire men skit.
- st_goliath 1y ago
  Now that's funny. The irony here is that, besides German (native), I do speak some HSK4-ish Mandarin as a 3rd language. A few years ago, a single line Chinese comment next to a blob of magic hex values did help me figure out a bug in a touch controller driver :-)
wucke13 1y ago
I have dedicated a large chunk of my (arguably short) professional career on improving upon this, mostly in the safety critical software domain. What was your experience back then, what made you leave ultimately, and what do you do now?

adwn 1y ago

As much as I wish this would come true, there's little chance for a full, end-to-end open source toolchain for Xilinx or Altera FPGAs that's competitive with the vendor tools. The reason for this is that there's no publicly available documentation of the signal routing configuration or the bitstream format, which are required for the final two steps in the chain. I don't see the two market leaders releasing this information anytime soon, and reverse engineering it from the data files is probably rather difficult. The synthesis discussed in the linked page is one of the earliest steps, and from the point of view of open source implementations, the simplest one, because all necessary information is freely available.

aappleby 1y ago
"there's no publicly available documentation of the signal routing configuration or the bitstream format" Both of things either have already been reverse-engineered, or are in the process of being reverse-engineered.
- robinsonb5 1y ago
  The reverse engineering efforts are impressive (though as I understand it, limited to Xilinx series 7 and Cyclone V) but without robust and reliable timing data to go with the rest of the chip data, they can't give you the same level of confidence that a design will work across a range of a devices and operating conditions.
  - amirhirsch 1y ago
    For the curious: the process of discovering the logic and route timings for an FPGA device is to use ring oscillators (three series inverters) and compare counters against a known clock. Place the inverters all over to test every LUT, and use every routing path to test each path's timing.
- adwn 1y ago
  > Both of things either have already been reverse-engineered, or are in the process of being reverse-engineered. Please provide a source for this claim. Yosys, for example, can't route [1] designs even for Xilinx 7-series devices, and that architecture has been introduced 15 years ago. [1] Not to be confused with synthesis, mapping, or placing, all of which come earlier in the flow, and for all of which sufficient information is public available.

tverbeure 1y ago

The installation can be around 100GB, which is a lot, but you have to distinguish the build part from the IDE. I hardly ever use the IDE and just use a Makefile. The open source tools still lack too many features to be useful for non-hobby development.