|
BobHoward posted:*good reality check was here!* movax posted:It is cool though, that you can instantiate and implement them in FPGA-based designs. This eats into the "market share" for PicoBlaze/MicroBlaze/Nios II/etc. but I feel like if I was Xilinx or Altera, saving the resources in supporting my own synthesizable processor and instead hopping onto the RISC-V train would be the way to go. This comes close to my sandbox rant on open-source silicon / open FPGA / all that poo poo, I'll save that for later. I'm a little disappointed to hear that the ISA isn't blazing any particularly new trails, but excited about the idea of implementing what I can of it on an FPGA for fun and learning 
|
#
?
Feb 9, 2019 01:29
|
|
|
|
| # ? May 13, 2024 09:08 |
|
|
The newest Jetson (Xavier) has a Cortex A55 with 8 cores and it is pretty sweet. Have a couple dev kits at work, Gen4 x8 PCIe slot on it too! Runs a full on desktop linux on it no sweat. Are there any RISC-V devices with similar power to a Cortex-5x to be able to run a full Linux (ie not busybox)? Would like to make a board controller/logger etc in the near-ish future.
|
|
#
?
Feb 9, 2019 01:34
|
|
|
Sidesaddle Cavalry posted:I'm a little disappointed to hear that the ISA isn't blazing any particularly new trails, but excited about the idea of implementing what I can of it on an FPGA for fun and learning There's a lot of example projects / designs out for really common dev-boards like the Arty-7 and TinyFPGAs. The latter has been seeing movement in open-source toolchains like Yosys/etc, but so far my understanding is that's all been independent developers / loosely funded by the guys doing the quantum physics / specialized lab equipment hardware out of Hong Kong. Pretty sure there's a board out with the MCU-class SiFive part that is out as well for development.
|
|
#
?
Feb 9, 2019 01:34
|
|
|
priznat posted:The newest Jetson (Xavier) has a Cortex A55 with 8 cores and it is pretty sweet. Have a couple dev kits at work, Gen4 x8 PCIe slot on it too! God, the Xavier is sweet. Was working on a MIPI Camera solution for a client that had to stitch together stuff with an UltraScale+ glued to the Jetson TX2. Having the Xavier there would have helped so much. Are you looking for silicon or RTL for RISC-V? Do you mean like a Cortex-A5x, or a Cortex-M5/-R5 like part?
|
|
#
?
Feb 9, 2019 01:37
|
|
|
priznat posted:The newest Jetson (Xavier) has a Cortex A55 with 8 cores and it is pretty sweet. Have a couple dev kits at work, Gen4 x8 PCIe slot on it too! A busy box based user land is “full” Linux. You’re free to waste flash and RAM on a “real” user land if you want. All you need for a full Linux is a mmu.
|
|
#
?
Feb 9, 2019 01:38
|
|
|
movax posted:It is cool though, that you can instantiate and implement them in FPGA-based designs. This eats into the "market share" for PicoBlaze/MicroBlaze/Nios II/etc. but I feel like if I was Xilinx or Altera, saving the resources in supporting my own synthesizable processor and instead hopping onto the RISC-V train would be the way to go. This comes close to my sandbox rant on open-source silicon / open FPGA / all that poo poo, I'll save that for later. Good point. It would be interesting to see area / frequency comparisons between a RISC-V and comparably configured vendor soft cores. At least with Xilinx, part of the sales pitch for MicroBlaze was that they'd carefully designed the ISA to min-max area and frequency on their FPGAs. On the other hand, Xilinx has had a lot of success with Zynq, which integrates hard Cortex-A and Cortex-M cores into a FPGA. If they wanted to move off MicroBlaze, it'd make a lot of sense to go for an ISA matching their hard CPU cores.
|
|
#
?
Feb 9, 2019 05:00
|
|
|
movax posted:Are you looking for silicon or RTL for RISC-V? Do you mean like a Cortex-A5x, or a Cortex-M5/-R5 like part? Silicon, however something that had some FPGA element would be pretty sweet as we'd have dedicated logic for power supply sequencing, resets, bootstrap pin setting, etc. In the past I've used a Zynq and it was ideal with the combination of a really flexible set of interfaces to the CPU along with some programmable logic. Previous to that I used an AVR32 with busybox and it was a bit of a hassle to update and add packages to. Things have probably advanced since then though. Booting from a microSD (readonly - it gets corrupted WAY too fast if you leave it in the hands of impatient engineers just power cycling boards) to ramdisk or even better via network boot is great. I am hoping to sell my boss on adding a cpu either Cortex-A5x or something else similarly capable to our next test platform. It would be great to only require one ethernet cable instead of a bunch of uart to USB and various other cables, along with the ability to cycle power to sections of the DUT via web interface or something like that. I've got a laundry list of reasons to do it, unfortunately the other side is "BOM cost" and "development time". Something that connects via mezzanine connector would help with the BOM costs as not all platforms will require it (ie the ones we send to customers).. This probably should go in a raspberry pi thread or something like that, any embedded CPU ones on the forum?
|
|
#
?
Feb 9, 2019 05:19
|
|
|
priznat posted:Silicon, however something that had some FPGA element would be pretty sweet as we'd have dedicated logic for power supply sequencing, resets, bootstrap pin setting, etc. In the past I've used a Zynq and it was ideal with the combination of a really flexible set of interfaces to the CPU along with some programmable logic. Previous to that I used an AVR32 with busybox and it was a bit of a hassle to update and add packages to. Things have probably advanced since then though. Sounds like you're building a super configurable test platform kind of thing. Zynq is definitely a good choice for something that can easily run Linux and has a ton of FPGA logic, but the UltraScale+ is almost certainly overkill for your application (I think). Zynq-7000, especially the smaller ones wouldn't be too much scar, but the dual A9s might be anemic depending on what kind of workload you have in mind. The stock ARM memory controller on the PS is definitely anemic. What you mentioned about BOM cost and such though...perhaps a Zynq SoM from Trenz, Enclustra or some other vendor might work out? That saves you from the detailed design of power / DDR layout / etc and gives you 2-3 edge connectors (usually) that'll expose a bunch of FPGA logic and some of the hard-wired peripherals. Usually the SoMs include an Ethernet PHY and/or USB PHY and all you have to supply is magnetics + a connector, which isn't awful. If you don't need any FPGA stuff at all, maybe an ARM SoC module from someone like Toradex would work? They slap an i.MX7 or similar type of part on a module and then you build a carrier board around it. A test equipment architecture I developed (But never got the chance to build) was centered around using PCI Express over fiber as the serialization mechanism, and then instantiating everything you needed on the FPGA and expose via memory-mapped I/Os. 69 16550A UARTs, 8 CAN controllers, whatever you wanted. Didn't really care about USB, because gently caress USB, but a PCIe switch could always be introduced to go to the least lovely USB 3.0 controller available. Still implementable with a SOM (assuming transceivers) but my basic philosophy there was exposing all the devices to Linux as memory-mapped devices and configuring the device-tree accordingly and using the pre-existing drivers for the controllers that are instantiated. Once you have the devices available to Linux properly, any engineer who can write Python is now a test engineer. quote:This probably should go in a raspberry pi thread or something like that, any embedded CPU ones on the forum? I'm wondering if we have the mass for just a comp arch thread, or maybe comp arch + embedded systems. Thoughts from the regulars / lurkers here?
|
|
#
?
Feb 9, 2019 05:36
|
|
|
BobHoward posted:Good point. It would be interesting to see area / frequency comparisons between a RISC-V and comparably configured vendor soft cores. At least with Xilinx, part of the sales pitch for MicroBlaze was that they'd carefully designed the ISA to min-max area and frequency on their FPGAs. I think the issue with ARM is that the RTL would always be black-boxed / encrypted and simulation would likely be a hilarious mess. Microsemi FPGAs with ARM options, if I recall correctly, simply had a static layout / configuration for a Cortex-M0 that if you wanted to use, consumed specific LUTs/resources for it to function correctly. Leaving their hard CPU cores as industry-standard Cortex-Axx and Cortex-Rxx but letting the FPGA-side use RISC-V for basic control-plane or little flow control might work out OK in the long run. But, I'm not sure what the pressure is on MicroBlaze or PicoBlaze where they could not already serve that application. I would think the influence there is if you're prototyping something destined for an ASIC on a big FPGA in which case you are definitely thinking about what standard cells your design is ending up on, and licensing you may have to pay.
|
|
#
?
Feb 9, 2019 05:39
|
|
|
movax posted:Sounds like you're building a super configurable test platform kind of thing. Zynq is definitely a good choice for something that can easily run Linux and has a ton of FPGA logic, but the UltraScale+ is almost certainly overkill for your application (I think). Zynq-7000, especially the smaller ones wouldn't be too much scar, but the dual A9s might be anemic depending on what kind of workload you have in mind. The stock ARM memory controller on the PS is definitely anemic. What you mentioned about BOM cost and such though...perhaps a Zynq SoM from Trenz, Enclustra or some other vendor might work out? That saves you from the detailed design of power / DDR layout / etc and gives you 2-3 edge connectors (usually) that'll expose a bunch of FPGA logic and some of the hard-wired peripherals. Usually the SoMs include an Ethernet PHY and/or USB PHY and all you have to supply is magnetics + a connector, which isn't awful. Zynq would be ideal and I'm fairly familiar with it already, but I could see us getting funnelled to running a RISC-V SoC FPGA as there's a bit of a push internally to move towards these. Probably something like the PolarFire SoC. There is definitely the requirement for some FPGA elements and the PolarFire is definitely nice because it is flash, not SRAM based for quicker booting CPLD style. Our devices have a lot of peripherals attached (GPIO muxed as TWI, SPI, UARTs) and it would be really nice to just have them all connected up to an SoC onboard rather than having to have connectors on the board to connect to whatever or loopback. Even things like being able to route clock signals using a FPGA to the various inputs/outputs would really help spare manual cable changing. Not having DIP switches for bootstrapping, and a bunch of other ports taken off will really help reduce the size of the board which is pretty drat big for something expected to fit in a server. I just have no idea how full featured the linux will be with these.. Don't really care about real time stuff, but having enough threads for the various interfaces would be a must. I'd really dig a comp arch thread, I'm mostly into the PCIe side of things so it would be good for learning and providing some info. Gen5 baby! 
|
|
#
?
Feb 9, 2019 06:08
|
|
|
movax posted:I'm wondering if we have the mass for just a comp arch thread, or maybe comp arch + embedded systems. Thoughts from the regulars / lurkers here?
|
|
#
?
Feb 9, 2019 06:52
|
|
|
hobbesmaster posted:A busy box based user land is “full” Linux. You’re free to waste flash and RAM on a “real” user land if you want. All you need for a full Linux is a mmu. Please don't be the Linux pedant that everyone hates.
|
|
#
?
Feb 9, 2019 08:33
|
|
|
I found this while reading up on RISC-V, a complete PC (64 bit quadcore, 8GB ECC RAM, Radeon GPU, Gigabit, USB, M.2 and SATA) running Linux (Fedora or Debian). It's based on the SiFive Unleashed SBC with an multiple expansion board and PCIe cards. https://abopen.com/news/building-a-risc-v-pc/ https://github.com/westerndigitalcorporation/RISC-V-Linux/
|
|
#
?
Feb 9, 2019 09:48
|
|
|
Yeah if Williamette had shipped with non-RD RAM support, AMD probably wouldn't exist today lol
|
|
#
?
Feb 9, 2019 11:55
|
|
|
Be dog slow on sdram.
GRINDCORE MEGGIDO fucked around with this message at 13:00 on Feb 9, 2019 |
|
#
?
Feb 9, 2019 12:55
|
|
|
I think you were missing the point of my argument, namely, that Intel could've probably effectively killed AMD in 2000/2001 if they had not been developing Itanium and simultaneously trying to squeeze the PC market to the same affect, lock the industry into their tech forever. The tbird came along right as a) people just getting PCs were like, "hurrr internet" and buying el cheapos and b) enthusiasts were fed up with Intel prices.
|
|
#
?
Feb 9, 2019 13:31
|
|
|
Who are you talking to? I'm posting williamette would be slow without rdram. I'm not debating lol AMD hypotheticals.
GRINDCORE MEGGIDO fucked around with this message at 17:00 on Feb 9, 2019 |
|
#
?
Feb 9, 2019 16:45
|
|
|
GRINDCORE MEGGIDO posted:Who are you talking to? I'm posting williamette would be slow without rdram. I'm not debating lol AMD hypotheticals. and I'm saying the two are inexorably linked. Intel could've plodded along forever with the marketshare they had at that juncture, eventually bleeding AMD dry, if they hadn't let the low end of the market slip away. They gave AMD a finger hold and they used it to pole vault into the Athlon XP. At the low end, no one would've cared if Williamette was slow with DDR, it still would've been a dum dum dum dum Intel machine
|
|
#
?
Feb 9, 2019 16:58
|
|
|
I don't care, like I said before I'm not interested. I'm just observing it would be slow, which it would be.
|
|
#
?
Feb 9, 2019 17:04
|
|
|
GRINDCORE MEGGIDO posted:I don't care, like I said before I'm not interested. I'm just observing it would be slow, which it would be. PhilsComputerLab had a video testing this exact scenario (AMD Thunderbird on DDR vs P4 Willamette on SDR and RDRAM): https://www.youtube.com/watch?v=zAF48Y5RAl8&t=688s tl;dw: Thunderbird beats or matches the P4 with RDRAM on most tests, P4 with SDR loses badly across the board.
|
|
#
?
Feb 9, 2019 17:31
|
|
|
Mr.Radar posted:PhilsComputerLab had a video testing this exact scenario (AMD Thunderbird on DDR vs P4 Willamette on SDR and RDRAM): Interesting - it didn't drop as much as I thought on sdr. I thought SDR would decimate the performance.
|
|
#
?
Feb 9, 2019 17:58
|
|
|
Mr.Radar posted:PhilsComputerLab had a video testing this exact scenario (AMD Thunderbird on DDR vs P4 Willamette on SDR and RDRAM): Absolutely fair, but meaningless to the lemming market, which is how AMD made all its money at this juncture. I would argue if they had a meaningful, competitive, entry level processor, because of their cache (not cache) they could've put AMD 6 feet under.
|
|
#
?
Feb 9, 2019 18:00
|
|
|
Crunchy Black posted:Absolutely fair, but meaningless to the lemming market, which is how AMD made all its money at this juncture. You seem real cool
|
|
#
?
Feb 9, 2019 18:39
|
|
|
Crunchy Black posted:Absolutely fair, but meaningless to the lemming market, which is how AMD made all its money at this juncture. AMD generally wasn't at all liked back then by most, usually seen as a budget chip maker for poor people, and they only got somewhat cast as the underdog making a comeback after the K7 demonstrated itself clearly in terms of performance. It was a real shocker at the time because Tomshardware had already released some benches on a engineering sample slot A Athlon and it did poorly. The early expectations were it'd be a screw up worse than the K5 that might sink the company! If there was a "lemming market" at the time it was all those buying the Willamette P4's and RDRAM. Crunchy Black posted:I would argue if they had a meaningful, competitive, entry level processor, because of their cache (not cache) they could've put AMD 6 feet under.
|
|
#
?
Feb 9, 2019 22:56
|
|
|
Yeah, there was a long period where AMD had decent chips but the chipsets available for them were fuckin’ awful. After loving around with crash-prone AMD/VIA systems, I swore I’d buy only Intel, and until the dual-core Athlon64/nForce combo became available, I suffered along with hot-running Netburst chips, ‘cause they were at least stable. Hot take: VIA did more to hurt AMD than Intel did
|
|
#
?
Feb 9, 2019 23:04
|
|
|
JnnyThndrs posted:Yeah, there was a long period where AMD had decent chips but the chipsets available for them were fuckin’ awful. Wiki says there was a AMD 761 chipset too so maybe that was the one for socket A instead and not the 750 like I thought. The issue with the VIA chipsets were the drivers. Usually took a few months after release for them to get really stable. But back then many were still on Win98SE or WinME so it hardly mattered.
|
|
#
?
Feb 9, 2019 23:24
|
|
|
I remember buying a Soyo Dragon for my socket a machine and thinking It was the hottest poo poo around. I am actually surprised that Soyo is still around today
|
|
#
?
Feb 9, 2019 23:38
|
|
|
PC LOAD LETTER posted:AMD actually had their own chipset for the Slot A Athlons and I think some of the early socket A mobo's too. It was called AMD 750 Irongate and was generally pretty stable though most of the mobo's it was put in were the low-ish end or unexciting ones. For some reason AMD didn't want to do their own chipset at the time, a major mistake, and it went away pretty quickly once VIA KT133 got popular. I had a FIC mobo that used it but no one seems to believe it existed anymore! Yeah more like those loving VIA chipsets were completely unstable pieces of poo poo. Which is why I never used an Athlon.
|
|
#
?
Feb 9, 2019 23:44
|
|
|
KKKLIP ART posted:I remember buying a Soyo Dragon for my socket a machine and thinking It was the hottest poo poo around. I am actually surprised that Soyo is still around today That iteration was liquidated in 2009 apparently. https://en.wikipedia.org/wiki/Soyo_Group
|
|
#
?
Feb 9, 2019 23:45
|
|
|
redeyes posted:Yeah more like those loving VIA chipsets were completely unstable pieces of poo poo. Which is why I never used an Athlon. edit:\/\/\/\/\/\/\/\/ Fair enough. If you were doing business stuff than stability would be the prime thing to focus on. PC LOAD LETTER fucked around with this message at 23:58 on Feb 9, 2019 |
|
#
?
Feb 9, 2019 23:52
|
|
|
PC LOAD LETTER posted:You didn't even like the NV chipsets either? ATi had chipsets for AMD too that most seemed to like for their stability and iGPU's from what I remember. To be honest at that time I supported a bunch of dot com start up networks and I all I cared about was overall quality and not having to go back and screw around with systems. Intel was all I used at that point even though they were surely slower and hotter.
|
|
#
?
Feb 9, 2019 23:56
|
|
|
Crunchy Black posted:Absolutely fair, but meaningless to the lemming market, which is how AMD made all its money at this juncture. I would argue if they had a meaningful, competitive, entry level processor, because of their cache (not cache) they could've put AMD 6 feet under. Why is it nobody who insists on using the word 'cachet' knows how to actually spell it? Also since it's been brought up, what was with AMDs stubborn insistence on making other companies develop the actually usable chipsets for its CPUs back then? It seems like it always went through the same basic lifecycle. The Via KT133A was the the best thing going, until nForce, then the Via was a heap of poo poo (I assume it was always actually a piece of poo poo). Then eventually nForce became regarded as a heap of poo poo eventually, they just wasn't anything good to replace it with IIRC.
|
|
#
?
Feb 10, 2019 00:17
|
|
|
Chipsets represented significant development effort and perhaps AMD didn't have the team(s) to support that development in addition to staying afloat working on new CPU designs. The move to integrating the memory controller on CPU die likely sealed the fate (at least for Intel platforms) in having 3rd party chipset development. Modern PCHs keep the older process equipment well utilized and are intimately connected to the processor(s) they support.
|
|
#
?
Feb 10, 2019 00:24
|
|
|
priznat posted:Zynq would be ideal and I'm fairly familiar with it already, but I could see us getting funnelled to running a RISC-V SoC FPGA as there's a bit of a push internally to move towards these. Probably something like the PolarFire SoC. There is definitely the requirement for some FPGA elements and the PolarFire is definitely nice because it is flash, not SRAM based for quicker booting CPLD style. Oh yeah, PolarFire is super interesting and they've squarely targeted the low cost + mid-range transceiver market that Arria sort of used to target. And they (Microchip) is right on-board the RISC-V train so you've got that going as well. Best Linux support I've seen for these types of platform is still the Xilinx maintained tree. PolarFire would likely have the "full" featured Linux in the sense of you've got a MMU but no idea about the threading or level of support when it comes to device tree overlays and things like that. I'd think something like Xenomai or RT-Linux would actually let you better setup scheduling / priorities to service all of your various peripherals.
|
|
#
?
Feb 10, 2019 00:29
|
|
|
I remember VIA and Creative Labs having finger pointing game as to who was to blame for bad audio
|
|
#
?
Feb 10, 2019 00:43
|
|
|
WhyteRyce posted:I remember VIA and Creative Labs having finger pointing game as to who was to blame for bad audio Hint: it was both of them. I was so very glad when motherboards started integrating solidly decent audio solutions, so that we didn't have to deal with any more SoundBlaster driver bullshit.
|
|
#
?
Feb 10, 2019 01:02
|
|
|
movax posted:Chipsets represented significant development effort and perhaps AMD didn't have the team(s) to support that development in addition to staying afloat working on new CPU designs. Chipsets are dumb tho just hang poo poo over the pcie bus or bake it into the io core. I can see why they just asked asmedia to slap together a bunch of peripheral controllers into one thing and called it a day
|
|
#
?
Feb 10, 2019 01:17
|
|
|
PC LOAD LETTER posted:You didn't even like the NV chipsets either? ATi had chipsets for AMD too that most seemed to like for their stability and iGPU's from what I remember. I built a NV chipset Athlon XP 2500+ gaming system back in the day and the chipset was quite buggy.
|
|
#
?
Feb 10, 2019 01:31
|
|
|
I read Windows itself threw audio under the bus after XP (or was it Vista?). All it really supported was stereo mixing. To this day windows audio is a shitshow, I think most people have given up on sound cards in general.
|
|
#
?
Feb 10, 2019 01:38
|
|
|
|
| # ? May 13, 2024 09:08 |
|
|
DrDork posted:I was so very glad when motherboards started integrating solidly decent audio solutions, so that we didn't have to deal with any more SoundBlaster driver bullshit. redeyes posted:I read Windows itself threw audio under the bus after XP (or was it Vista?). All it really supported was stereo mixing. To this day windows audio is a shitshow, I think most people have given up on sound cards in general. Combat Pretzel fucked around with this message at 02:05 on Feb 10, 2019 |
|
#
?
Feb 10, 2019 01:42
|
|
