Their toolchain is a fucking joke. It's a monumental disaster. I have no idea who is maintaining (and i use that word hesitantly) it, but I'm fairly certain they are indistinguishable from an infinite number of mildly retarded monkeys.
Xilinx: you guys suck ass and I'm glad I'm done with the FPGA industry in my current career.
I work closely with many of the Xilinx developers. They've got some really bright folks working on some exciting things. Their back end tools are quite good these days.
The problem is they've (long) suffered from extreme tunnel-vision. Their envisioned way of solving things is the only way of solving things. Any variance on "Their way" is just a customer being troublesome.
And the Xilinx way of doing front-end design still is solidly wedged in the 80s - one designer running a schematic capture like tool. Then pushing GUI buttons through the implementation steps... Sigh.
Xilinx management also should also apply the ban-hammer to any new file types, and rely on industry standards more. MHS, HDF, XCIX, DCP, BD.TCL, NCD, NGD... The list of Xilinx filetypes could fill multiple Answer Records.
At least the Hurd team understands the importance of SCM and deterministic tools that don't require a UI.
This. SCM for Xilinx was an afterthought in their newest tools (Vivado). They've tried about 5 iterations of recommended methodologies to try and back fit SCM onto current (UI) based flows. None of them have worked; breaking even the most basic SCM fundamentals: human-editable source files, branching, merging, etc...
It's astounding to me because this was the case as long as *15 years ago*. Why on earth is anybody saying Xilinx has "really bright folks" working for them and why does anybody take them seriously?
What a fucking joke. Sorry Xilinx, you guys are fucking retards.
I've never been impressed with any of their tools they tried to port to unix. If they have smart software devs, they definitely don't understand anything but Windows.
And the Xilinx way of doing front-end design still is solidly wedged in the 80s - one designer running a schematic capture like tool. Then pushing GUI buttons through the implementation steps... Sigh.
Sounds like the clicky-clicky hell that's SSIS - Microsoft's ETL bolt-on for SQL Server. It's usually quicker to write a C# program to create a dynamic SSIS package on the fly than it is to go through all the clicky madness of setting up an SSIS package to import CSV files with more than a couple of dozen columns.
You should have seen the blank stare I got from a dyed in the wool xilinx guy when I asked him how he captures the 1000 UI clicks he does in a reproducible file that can be stored in SCM.
Ouch... been there, done that. I too have resorted to writing a one-off parser rather than rely on the MS GUI for large (wide) imports.
Painful memories there.... like the inclusion of special characters that the MS parser didn't expect - months down the road. Daily imports of thousands of records, and we took months to hit a weird edge case where special characters made it into a text field and screwed up the rest of the line. And it took a few days for anyone to notice....
Xilnx is full of incompetents (Score:2)
Their toolchain is a fucking joke. It's a monumental disaster. I have no idea who is maintaining (and i use that word hesitantly) it, but I'm fairly certain they are indistinguishable from an infinite number of mildly retarded monkeys.
Xilinx: you guys suck ass and I'm glad I'm done with the FPGA industry in my current career.
Re:Xilnx is full of incompetents (Score:5, Informative)
I work closely with many of the Xilinx developers. They've got some really bright folks working on some exciting things. Their back end tools are quite good these days.
The problem is they've (long) suffered from extreme tunnel-vision. Their envisioned way of solving things is the only way of solving things. Any variance on "Their way" is just a customer being troublesome.
And the Xilinx way of doing front-end design still is solidly wedged in the 80s - one designer running a schematic capture like tool. Then pushing GUI buttons through the implementation steps... Sigh.
Xilinx management also should also apply the ban-hammer to any new file types, and rely on industry standards more. MHS, HDF, XCIX, DCP, BD.TCL, NCD, NGD... The list of Xilinx filetypes could fill multiple Answer Records.
Re: (Score:2)
Re: (Score:2)
At least the Hurd team understands the importance of SCM and deterministic tools that don't require a UI.
Re: (Score:2)
At least the Hurd team understands the importance of SCM and deterministic tools that don't require a UI.
This. SCM for Xilinx was an afterthought in their newest tools (Vivado). They've tried about 5 iterations of recommended methodologies to try and back fit SCM onto current (UI) based flows. None of them have worked; breaking even the most basic SCM fundamentals: human-editable source files, branching, merging, etc...
Re: (Score:2)
It's astounding to me because this was the case as long as *15 years ago*. Why on earth is anybody saying Xilinx has "really bright folks" working for them and why does anybody take them seriously?
What a fucking joke. Sorry Xilinx, you guys are fucking retards.
Re: (Score:2)
I've never been impressed with any of their tools they tried to port to unix. If they have smart software devs, they definitely don't understand anything but Windows.
Re: (Score:0)
And the Xilinx way of doing front-end design still is solidly wedged in the 80s - one designer running a schematic capture like tool. Then pushing GUI buttons through the implementation steps... Sigh.
Sounds like the clicky-clicky hell that's SSIS - Microsoft's ETL bolt-on for SQL Server. It's usually quicker to write a C# program to create a dynamic SSIS package on the fly than it is to go through all the clicky madness of setting up an SSIS package to import CSV files with more than a couple of dozen columns.
Re:Xilnx is full of incompetents (Score:4, Informative)
You should have seen the blank stare I got from a dyed in the wool xilinx guy when I asked him how he captures the 1000 UI clicks he does in a reproducible file that can be stored in SCM.
Re: (Score:2)
Ouch... been there, done that. I too have resorted to writing a one-off parser rather than rely on the MS GUI for large (wide) imports.
Painful memories there.... like the inclusion of special characters that the MS parser didn't expect - months down the road. Daily imports of thousands of records, and we took months to hit a weird edge case where special characters made it into a text field and screwed up the rest of the line. And it took a few days for anyone to notice....
Feel my pain, people. Feel my
Re: (Score:2)
As someone who just read a Verilog book and is looking for a good place to start with real hardware, what would you recommend?