AMD Xilinx Kria KR260 Robotics Kit(servethehome.com)
servethehome.com
AMD Xilinx Kria KR260 Robotics Kit
https://www.servethehome.com/amd-xilinx-kria-kr260-robotics-kit-launched/
5 comments
I definitely agree with the second paragraph. I got lost in tooling the first time I tried to learn FPGA. The second time, I got an iCE40 and used iverilog, flashrom and other open source tools. And it was extremely simple! Based on what I saw in the video (having to create a user just to download the software), I don't think FPGA manufacturers get this part.
While there are clear inefficiencies in FPGA tooling, I can assure you the complexity of the tooling is 2 or 3 orders of magnitude higher than microcontrollers.
Not that I don't wish to have tooling available for me to modify, but I also understand this is thousand years of man work right there...
Not that I don't wish to have tooling available for me to modify, but I also understand this is thousand years of man work right there...
The issue is it's locked away in proprietary garbage and has been for decades. There just isn't the same level of interest for FPGAs as there is for micro-controllers or embedded linux platforms.
I don't doubt your thousand hour quote. But at the same time I'd say there is probably 10k years of garbage and cruft built in the current toolsets.
FPGAs need an LLVM moment. Right now, the current set of HDLs available are terribly unergonomic and pretty much re-implemented for each FPGA provider. We are roughly at the K&R C era for FPGAs. To get out of that, we need good middleware and open standards.
Once that happens, I think we can finally start making some real higher level hardware description languages. FPGA programing, in particular, seems like it would be fairly amenable to functional programming concepts.
I don't doubt your thousand hour quote. But at the same time I'd say there is probably 10k years of garbage and cruft built in the current toolsets.
FPGAs need an LLVM moment. Right now, the current set of HDLs available are terribly unergonomic and pretty much re-implemented for each FPGA provider. We are roughly at the K&R C era for FPGAs. To get out of that, we need good middleware and open standards.
Once that happens, I think we can finally start making some real higher level hardware description languages. FPGA programing, in particular, seems like it would be fairly amenable to functional programming concepts.
> Not that I don't wish to have tooling available for me to modify, but I also understand this is thousand years of man work right there...
The same could be said about highly efficient optimizing compilers and kernels. Nevertheless, we have GCC and Linux.
The same could be said about highly efficient optimizing compilers and kernels. Nevertheless, we have GCC and Linux.
Compare iverilog to VCS or xcelium, while it's brilliant, it's not even close in features or performance, and there is nothing preventing the OSS community from making it better, so the question is why? is it just a lack of people with the right mix of skills (both SW and HW is rare enough), or something else?
Synthesis, place and route are all much harder than simulation, so I don't think tools like vivado would suddenly be better if open sourced. Also I think vivado is great, but I seem to be in the minority on that one, but I guess it's my perspective as a HW designer dealing with HW tools all my life, vivado is a breath of fresh air.
Synthesis, place and route are all much harder than simulation, so I don't think tools like vivado would suddenly be better if open sourced. Also I think vivado is great, but I seem to be in the minority on that one, but I guess it's my perspective as a HW designer dealing with HW tools all my life, vivado is a breath of fresh air.
I'd say PlatformIO is a better analogy -- a framework that lets you use virtually whatever HAL you're familiar with (Arduino, Zephyr, freeRTOS, mbed, etc) with whatever hardware and its corresponding toolchains.
I agree. But unfortunately Symbiflow is not up to spec at the moment. Once it has the basics down this should be the path forward.
I was really surprised to see this board featured as a primary tab[1][2] on Ubuntu's main download page, right along side major use cases like "server" and "desktop" (and yes, Raspberry Pi). IMO this already puts this board far ahead of many others in the sea of dev boards.
[1] https://ubuntu.com/download [2] https://ubuntu.com/download/amd-xilinx
[1] https://ubuntu.com/download [2] https://ubuntu.com/download/amd-xilinx
Why they keep avoiding publishing the programing hardware interface of FPGAs?
What are the real reasons?
trash human beings? patent trolls? etc?
yes, I would like to know.
What are the real reasons?
trash human beings? patent trolls? etc?
yes, I would like to know.
I have worked at an FPGA company, but on soft-IP, so I have some expertise but I wouldn't consider myself an expert, but I've certainly talked to them. What I observed is that whilst there technically is a bit pattern being programmed to hardware, the rules surrounding what combination of bits is incredibly complex. The simplest example of this is that you could programme two registers, one to drive a net low, the other to drive a net high and just basically screw up your chip. The rules that prevent that aren't a set of last minute "sign-off the image" type rules. Thhey're embedded into every part of the compiler. There were game changing hardware resources that genuinely were going to be hidden from customers because we didn't have the software resources to actually expose them in a safe manner (honestly, it's really very complex).
Ok, so that's the technical reasoning. On the business side, FPGA companies (like basically every ASIC company today) produce 1 design and disable a bunch of stuff for market segmentation. VU7P? Well that's physically the same as the VU5P but the software limits what you can compile on to it. So to enable open source interfaces they'd need to add an entire layer of DRM ontop of the current solutions. You can argue about the ethics, but it is what it is. Also, marketing drove Altera and Xilinx. Don't get any ideas that these were silicon valley engineer led start ups. It was a marketing game, you see that in their leadership and I'd argue you saw it in their share price growth too.
Ok, so that's the technical reasoning. On the business side, FPGA companies (like basically every ASIC company today) produce 1 design and disable a bunch of stuff for market segmentation. VU7P? Well that's physically the same as the VU5P but the software limits what you can compile on to it. So to enable open source interfaces they'd need to add an entire layer of DRM ontop of the current solutions. You can argue about the ethics, but it is what it is. Also, marketing drove Altera and Xilinx. Don't get any ideas that these were silicon valley engineer led start ups. It was a marketing game, you see that in their leadership and I'd argue you saw it in their share price growth too.
>Also, marketing drove Altera and Xilinx. Don't get any ideas that these were silicon valley engineer led start ups. It was a marketing game, you see that in their leadership and I'd argue you saw it in their share price growth too.
If you think either one is past it's prime, what companies would you recommend for FPGA designs? Lattice?
If you think either one is past it's prime, what companies would you recommend for FPGA designs? Lattice?
I think it's a complete dead zone. It's a small niche between CPUS and ASIC and companies like Google, Tesla, Amazon have reached the scale where they can hop straight to ASIC for any real volume. Their economics are different - they're thinking about total cost of ownership which sucks for high static power FPGAs. The only hope is some powerful low-barrier to entry programming model, but that's a long-shot.
Sure, there'll be some revenue from prototypes, from standards settling, but really it's not a sustained volume, it's cyclical.
Sure, there'll be some revenue from prototypes, from standards settling, but really it's not a sustained volume, it's cyclical.
What other players there even are?
Lattice is the third and Microchip is likely the fourth.
After that theres Gowin, Anlogic and maybe Renesas?
ok, trash human beings.
What did I expect?
What did I expect?
I really don't think the hardware specs is the issue. OSS EDA is miles behind commercial EDA. It's great that there are efforts to create an open ecosystem, and there are some chips that are usable in those flows, but the SW is orders of magnitude behind the proprietary tools.
I don't like that these proprietary tools are thrashed also, tools like Vivado are immensely complicated and surprisingly easy to use compared with other hardware tools. ASIC synthesis would make your cry compared with how easy Vivado makes it for FPGAs. Sure its not perfect, but it is free to use for many devices, and includes simulation, debug, SDKs, etc.
I don't like that these proprietary tools are thrashed also, tools like Vivado are immensely complicated and surprisingly easy to use compared with other hardware tools. ASIC synthesis would make your cry compared with how easy Vivado makes it for FPGAs. Sure its not perfect, but it is free to use for many devices, and includes simulation, debug, SDKs, etc.
These companies are just twenty years behind the times. It’s why they lost the supercomputing market to NVidia. The FPGA vendors are also going to lose the DSP market to NVidia now, except for areas with extremely hard realtime requirements.
There are a whole lot of steps in between having a netlist and having useable hardware. Normally, if you're a large company, you have a small army of engineers handle that process and occasionally tell your architecture people that they need to fix up their designs here or there. When you target an FPGA, which is really more of an abstraction on top of silicon just like CPUs or GPUs are an abstraction on top of silicon, you're effectively paying them to do this process for you and mediate it via the software stack.
There's plenty to debate about where the boundary should be, but an almost universal constant is that ecosystems ossify around interfaces, so hardware companies will generally see giving up control as a borderline existential threat unless they're in the business of fishing pennies out of the gutter for margins.
There's plenty to debate about where the boundary should be, but an almost universal constant is that ecosystems ossify around interfaces, so hardware companies will generally see giving up control as a borderline existential threat unless they're in the business of fishing pennies out of the gutter for margins.
I encourage someone to correct me, but why are there so many development focused chips like this on the market?
If we compare with a raspberry pi (ignoring supply issues for the moment), they seem to cost upwards of $100, have less online support, sometimes require weird linux hacks, sometimes require special tooling for a RTOS.
The positives seem to be more ports, better specs, and more reliability in exchange. But does your typical robot project really need all that?
And if you're at that point, why not a mini ITX style board, or a modern cellphone with I/O breakouts? Even a cheap laptop I imagine could serve really well depending on what you're doing.
I guess my main question is what's the use case/market for this?
If we compare with a raspberry pi (ignoring supply issues for the moment), they seem to cost upwards of $100, have less online support, sometimes require weird linux hacks, sometimes require special tooling for a RTOS.
The positives seem to be more ports, better specs, and more reliability in exchange. But does your typical robot project really need all that?
And if you're at that point, why not a mini ITX style board, or a modern cellphone with I/O breakouts? Even a cheap laptop I imagine could serve really well depending on what you're doing.
I guess my main question is what's the use case/market for this?
It's the boards that are for development, not the chips. They are intended for development of a product which includes the chips on them, not as general purpose glue like raspberry pis or arduinos. And for this kind of development the cost of the boards is usually negligable compared to the other costs of development, so there's little price pressure on them (especially compared to competition on the price of the chip at scale). In fact it's generally in the interests of the companies producing such boards that their limited supply does not go towards people not intending on buying at least few thousand of their chips (and if you give them an indication that you are likely to buy a decent quantity, often you will be given these boards for free).
That said, there are sometimes modules like those mentioned in the article which are intended for production use in volume, though generally these are aimed at a segment of the market where there's about the right volume that saving the development costs of putting the chip onto the custom board direct (e.g. the PCB layout connecting the SoC to the DDR memory or getting a prototype board with enough layers to bring out all the signals on the chip) is worth the extra markup.
That said, there are sometimes modules like those mentioned in the article which are intended for production use in volume, though generally these are aimed at a segment of the market where there's about the right volume that saving the development costs of putting the chip onto the custom board direct (e.g. the PCB layout connecting the SoC to the DDR memory or getting a prototype board with enough layers to bring out all the signals on the chip) is worth the extra markup.
Your critics are more applicable to the similar robotics kits of NVIDIA and Qualcomm, which range from a little overpriced to extremely overpriced, in comparison with their alternatives like single-board computers with ARM chips from Rockchip or the like, small computers with Jasper Lake or even with cheaper Tiger Lake models, NUC-like computers with Intel or AMD CPUs, or bargain laptops (all these are under $500, while the ARM or Jasper Lake/Elkhart Lake systems are under $300, with many slower ARM SBCs under $100; the NVIDIA and Qualcomm kits range from $400 to $2000).
These kits from AMD Xilinx, i.e. Kria KV260 and Kria KR260, are very cheap in comparison with the other development systems that include an FPGA so powerful.
Their main defect is that Xilinx makes extremely few of them, so if you want to buy one you might have to wait many months or even years.
For projects that would not benefit much from a FPGA, a cheaper SBC or even just a microcontroller board of $10 or $20 would be a better choice.
However, if you have a clever idea that could be implemented with an FPGA, these new development kits are better than most FPGA boards that have been available previously.
Their main alternative are various boards with Xilinx Artix-7 FPGAs. There are boards in the same price range of a few hundred $, with FPGAs of similar size to those of the Kria kits. However the older Artix-7 FPGAs are significantly slower than the UltraScale+ used in the Kria kits, and they also do not have the 64-bit ARM cores included in UltraScale+ (which has a quadruple Cortex-A53 running Linux and also two 32-bit Cortex-R5F ARM cores, for hard real-time applications).
These kits from AMD Xilinx, i.e. Kria KV260 and Kria KR260, are very cheap in comparison with the other development systems that include an FPGA so powerful.
Their main defect is that Xilinx makes extremely few of them, so if you want to buy one you might have to wait many months or even years.
For projects that would not benefit much from a FPGA, a cheaper SBC or even just a microcontroller board of $10 or $20 would be a better choice.
However, if you have a clever idea that could be implemented with an FPGA, these new development kits are better than most FPGA boards that have been available previously.
Their main alternative are various boards with Xilinx Artix-7 FPGAs. There are boards in the same price range of a few hundred $, with FPGAs of similar size to those of the Kria kits. However the older Artix-7 FPGAs are significantly slower than the UltraScale+ used in the Kria kits, and they also do not have the 64-bit ARM cores included in UltraScale+ (which has a quadruple Cortex-A53 running Linux and also two 32-bit Cortex-R5F ARM cores, for hard real-time applications).
As mentioned, this sort of board is produced to sell chips and serve as a basic reference design for customers and support engineers who have to debug issues.
As for what a typical robotics project needs, the Zynq line is far, far nicer to program and certify than the corresponding alternatives from NXP and especially TI (at least once you've automated away the pain of xilinix' toolchain), plus you get a decent FPGA on the side and ROS support. Laptops and cell phones won't do any of that and couldn't be certified, regardless.
So yes, this is very much something people will want.
As for what a typical robotics project needs, the Zynq line is far, far nicer to program and certify than the corresponding alternatives from NXP and especially TI (at least once you've automated away the pain of xilinix' toolchain), plus you get a decent FPGA on the side and ROS support. Laptops and cell phones won't do any of that and couldn't be certified, regardless.
So yes, this is very much something people will want.
This has always been the case in the past, but these boards are build around the SOM's. You can just buy these as off-the-shelf components (not counting lead-time issues..). This makes FPGAs much more accessible especially for smaller companies, or not so high-volume projects. You would still need to design something to connect the SOM to, but much simpler than the entire PCB.
Is TI's toolchain still godawful?
TI's stuff is very 'mature' at this point, so yeah. It's hard to call it a worse experience than something like Vivado (to the extent those can be compared), but TI's HW is also pretty terrible whereas you're getting decent stuff with Xilinx when they deign to fill orders.
Dev-boards like this are to show-case the core chips.
They aren't meant to be, nor would Xilinx want to be in the business of, producing these at scale.
They want to sell the core-chip, dev-boards make it easier to assess without actually exposing any business-side ips.
They aren't meant to be, nor would Xilinx want to be in the business of, producing these at scale.
They want to sell the core-chip, dev-boards make it easier to assess without actually exposing any business-side ips.
These are more akin to advertisements than products.
This dev board is primarily focused on showcasing an FPGA which is a different animal compared to a Pi and other small computing platforms. Selling these Xilinx FPGAs for your PCB manufacturing is the thing they’re prepared to do at scale.
These boards are a combination of a SOM (system on a module) and a baseboard. The SOM's are actually designed to be used in commercial products, so they are sort of in the middle ground. You don't have to design a complex multi-layered PCB for the FPGA BGA, you can just replace the baseboard which should reduce complexity. Mini ITX board will be relatively very large and consume tons of power. Maybe OK for large robots, but not for compact low-power designs. If you can meet your requirements with a raspberry pi, or a single ARM style processor, then most people would choose that. FPGAs, especially the SoCs (multi-processor + FPGA) are used when HW acceleration & fixed low-latency are important, and also there is a lot of flexibility for customized peripherals.
Imagine if you had to solder every chip you want to evaluate and write software for on a custom PCB first. The number of chips you can evaluate would be very small as it takes a month to just design the evaluation PCB. So instead chip vendors provide their own evaluation boards for development purposes so you can start writing software from day one and design the final production PCB at the same time.
What we call ARM SBCs are actually electronics development boards which ironically have been used in production as is.
What we call ARM SBCs are actually electronics development boards which ironically have been used in production as is.
I think there also might be some consideration of ability to move from dev hardware to a more optimized mass market product. MiniITX boards or cellphones with I/O breakouts rely on much 'wider' supply chains with providers who have their own interests that might not be as amenable to setting up mass production with a customized version of the dev hardware 2-3 years down the line.
They also probably serve as gateway products, so someone might buy this kit for a hobby project and get familiar with Xilinx's ecosystem, leading them to then have a bias towards Xilinx for when they're in the workplace having to decide on an FPGA.
They also probably serve as gateway products, so someone might buy this kit for a hobby project and get familiar with Xilinx's ecosystem, leading them to then have a bias towards Xilinx for when they're in the workplace having to decide on an FPGA.
for higher performance, latency sensitivity, or a tight latency distribution, or interfacing with hardware (i.e. lvds)...there is a _really_ big difference between software running on top of linux and transistors (even if they are soft-configured)
bldc motor control is a fine example. yes, you can buy a controller and program it from linux, but if you want to integrate current feedback in some novel way you should really be doing that in hardware.
bldc motor control is a fine example. yes, you can buy a controller and program it from linux, but if you want to integrate current feedback in some novel way you should really be doing that in hardware.
I believe one of the really appealing aspects to an FPGA for robotics use is the ability to get very low latency in the loop from processing sensor input data to actuating motors / actuators in response to that data.
Has anyone used the new Vivado ML editions? They are claiming a 5x reduction in "compile times" by the use of machine learning.
I installed it recently for a new project but have not got around to testing it yet.
I installed it recently for a new project but have not got around to testing it yet.
My vision is: fpga world is now just like microcontrollers were in late 90's: a sea of proprietary inefficient tools. We need the Arduino equivalent for fpga: extremely easy to use and fully FLOSS.