[HN Gopher] AMD Xilinx Kria KR260 Robotics Kit Launched
___________________________________________________________________
AMD Xilinx Kria KR260 Robotics Kit Launched
Author : walterbell
Score : 78 points
Date : 2022-05-21 10:09 UTC (2 days ago)
(HTM) web link (www.servethehome.com)
(TXT) w3m dump (www.servethehome.com)
| d_tr wrote:
| 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.
| schaefer wrote:
| 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
| spicybright wrote:
| 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?
| adrian_b wrote:
| 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).
| AlotOfReading wrote:
| 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.
| ethbr0 wrote:
| Is TI's toolchain still godawful?
| kjsthree wrote:
| 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.
| rcxdude wrote:
| 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.
| convolvatron wrote:
| 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.
| omgJustTest wrote:
| 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.
| omgJustTest wrote:
| These are more akin to advertisements than products.
| dotnet00 wrote:
| 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.
| MobiusHorizons wrote:
| 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.
| sylware wrote:
| 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.
| amirhirsch wrote:
| 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.
| SilverBirch wrote:
| 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.
| sylware wrote:
| ok, trash human beings.
|
| What did I expect?
| marcodiego wrote:
| I'd consider it if they supported Symbiflow.
|
| 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.
| bajsejohannes wrote:
| 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.
| guepe wrote:
| 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...
| cogman10 wrote:
| 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.
| marcodiego wrote:
| > 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.
| tkanarsky wrote:
| 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.
___________________________________________________________________
(page generated 2022-05-23 23:01 UTC)