Lramseyer

The pattern I have observed in my friends and myself (when I was on dating apps) goes something like this: We get matches, some of those matches flake, don't respond, or don't pan out into anything. So we mitigate that emotional risk by talking to multiple people at once. As a result we're pulling the lever (swiping) and eventually getting the emotional payout of a match with someone cute. Then we see something we don't like in the person we matched with, so we're faced with the choice accepting someone for their flaws, or pulling the Skinner box lever (swiping.) I know it sounds reductive, but it preys on our addictive nature in a way that gets in the way of human connection. Eventually we snap out of it, but by that time, we have been on the app for several months or even years for some people. While it doesn't keep people single per se, it is not the most conducive means of cultivating genuine relationships. As a result people stay on the app for longer, and keeps the user base high.

Maybe I'm mis-attributing survivorship bias to malice. In other words, sure it's profitable for Tinder, but not inherently beneficial to society. Tinder might not actively trying to operate this way, but there is a large population of people that will gravitate towards the dating services that give them that high of variable rewards It's profitable for Tinder and all of it's look-alikes, so they continue to exist in the market.

The issue I take with all of it is the misalignment of incentives in the business model. Regardless of intention, there's an inherent disconnect. If Tinder has someone paying $500 a month, they're going to want to keep those payments coming. How would they do that?

One thing that doesn't sit well with me about most dating apps is that they operate under the paradigm where "If you're attractive, you're the product, not the customer" If you're getting likes, or swipes, or matches, or whatever the app wants to call it, why pay extra?

This can lead to a really perverse set of incentives like trying to keep your user base single. They have essentially turned dating into a Skinner box and used the inherent variable rewards to keep users addicted. Once users are addicted, you can play with their emotions by messing with the volatility and frequency of their rewards. This allows you to dangle a carrot in front of them and tell them that they can simply pay extra to bring the carrot closer.

Why can't apps monetize dates by suggesting cool date spots and activities? Maybe try to keep people engaged after the first 2 or 3 dates by gamifying cool activities and deep questions? At least this way it incentivizes human connection and experience, while making ad revenue.

Full Disclosure, I work for an FPGA company.

The mind blowing part of all of this is the fact that they were able to close timing at 771MHz. That is insanely fast for an FPGA. For perspective, most modern FPGAs run their designs at around 300MHz* While most of the heavy lifting in this design use hardened components like DSPs and FPUs, it's still very impressive to see!

What I didn't see talked about much was how memory is loaded in and out of the processor. I'm curious to see what the memory bandwidth numbers look like as well as the resource utilization of the higher level routing.

*For most hardware designs that aren't things like CPUs and GPUs, you don't always need a super high clock speed. You have a lot more flexibility to compute in space rather than in time (think more threads running slower.) The pros and cons of such tradeoffs are a bit of a complicated topic, but should at least be noted.

Since so many people are asking what "emulation" is, I'm going to respond to the parent comment instead:

"Emulation" refers to emulation of chip designs. When a chip has billions of transistors that are all connected to each other to perform higher level functions, you need to test out designs in order to make sure those higher level functions actually do what you expect them to. Most modern chip designs (at least the digital portions of them) are designed using what's called a Hardware Description Language or "HDL" such as System Verilog or VHDL. It's somewhat similar to traditional programming, except threads are nonexistent, so it's essentially an unholy bastardization of a markup language and a programming language. But I digress... These functions are then synthesized into their low level building blocks such as buses, gates, and registers, and are placed and laid out on a chip.

Going back to the part about billions of transistors; as you might imagine, testing of such designs must be rigorous and thorough. Only problem is that it's really, really computationally intensive. There are 2 ways of doing it: Simulation (CPU Based) and Emulation (FPGA Based) Simulation is slower, but yields more data like waveforms and whatnot (though you can get waveforms with emulation, but there are more limits.) Also, simulation takes less time to compile, since there's no place and route step.

I should also point out that there are 4 key simulation levels: Simulation Model (usually compiled C code) RTL Simulation (Functional level simulation) Gate level Simulation (simulating the individual gates) and physical simulation (where the transistors and trace routing are all accounted for.) Each level being roughly an order of magnitude more computationally intensive than the previous. Most time and engineering effort is spent on RTL level simulation, which is what can, and is often emulated on an FPGA, and why this product is so relevant to hardware designers.

I think this alternate future of a gigantic CCS network is a really long ways off. Have you ever tried to use non-Tesla DC fast charging? It's a mess! There aren't a lot of stalls, one of them is usually broken, and the payment processing is a mess! I thought people were exaggerating until I experienced it first hand. While I think they will eventually get their act together, I don't think it's unreasonable to claim that the terrible DC fast charging experience is a huge deterrent to non-tesla EV buyers right now. This ultimately creates a chicken and egg problem that results in such slow progress in the EV charging world (outside of Tesla.) It's why Tesla's US EV market share is around 60%.

I actually think this is great for Tesla in other ways in the nearer term. With other automakers switching to NACS, this removes a huge concern for would be non-Tesla EV buyers. Now you may think this would erode Tesla's market share, but I think it will convert far more ICE customers than Tesla customers. The net effect is a faster EV adoption, faster cultural acceptance of EVs, and more people considering Tesla in the near-mid term.

I fail to see how this negatively affects Ford, GM, and Rivian. They can retrofit the charge port relatively cheaply or deal with an adapter. Yes, it affects resale value of early customers. But that's how it goes with new technology, and buyers are naive to think otherwise. Besides, when compared to their ICE counterparts, they're probably still coming out ahead on maintenance.

I have a tinfoil hat theory that all of this environmental and safety regulation was amplified heavily by lobbying and/or propaganda efforts from the coal companies. On one hand, you can make the argument that nuclear fuel was the new silent invisible killer on the block (as opposed to coal mining and emissions which were known, but accepted since it had been around for decades) But when I read stuff like this, it seems as if regulation was heavily disproportionately applied to nuclear energy even despite it being a new and unfamiliar danger. Or maybe the coal industry simply was more successful at curbing regulation. After all, it was was a more mature industry financially and politically.

My theory might be speculative and totally off the mark. But when you compare deaths per TWh of energy produced, coal is responsible for almost 3 orders of magnitude more deaths than nuclear. So maybe the real question is "how has coal power stayed so cheap?" or "if we tried to make coal power as safe as nuclear, what would it cost?"

These are really good questions to be asking, and to help with that let's consider 3 attributes of compute complexity: time, space, and memory

The traditional way of computing on a CPU is in essence a list of instructions to be computed. These instructions all go to the same place (the CPU core) to be computed. Since the space is constant, the instructions are computed sequentially in time. Most programmers aren't concerned with redesigning a CPU, so we typically only think about computing in time (and memory of course)

On an FPGA (and custom silicon) the speedup comes from being able to compute in both time and space. Instead of your instructions existing in memory, and computed in time, they can be represented in separate logic elements (in space) and they can each do separate things in time. So in a way, you're trading space for time. This is how the speed gains are achieved.

Where this all breaks down is the optimization and scheduling. A sequential task is relatively easy to optimize since you're optimizing in time (and memory to an extent.) Scheduling is easy too, since, they can be prioritized and queued up. However, when you're computing in space, you have to optimize in 2 spatial dimensions and in time. When you have multiple tasks that that need to be completed, you then need to place them together and not have them overlap.

Think trying to fit a ton of different shaped tiles on a table, where you need to be constantly adding and removing tiles in a way that doesn't disrupt the placement of other tiles (at least not too often.) It's kind of a pain, but for some more constrained problem sets, it might make sense.

These aren't impossible problems, and for some tasks, the time or power usage savings is worth the additional complexity. But sequential optimization is way easier, and good enough for most tasks. However, if our desire for faster computing outpaces our ability to make faster CPUs, you may see more FPGAs doing this sort of thing. We already have FPGAs that are capable of partial reconfiguration, and some pretty good software tools to go along with it.

TL;DR: Geometry is hard.

Probably some Physical Design engineers who looked at the problem, and realized that it was a complex geometry problem that could be sped up buy parallelized computing. So they called up Synopsys (probably not TSMC) and were like "can you port this to CUDA?" The reason NVIDIA is taking credit for it is because Synopsys isn't know for its ability to deliver great software, and the folks at NVIDIA realistically probably wrote it.

I would offer a counter point: Chat GPT uses text, which is analogous to the MIDI of spoken language. Now, what's to prevent a speech to text and text to speech AI slapped on both ends to make it audibly conversational? Or train the franken-model model end to end in one monolithic model in hopes that it might make other interesting connections.

That being said I have seen very little in the AI transcription space (Listening to music, and outputting legible sheet music while identifying instruments) especially when it comes to multi-instrument music. I've also seen very little in the midi generation space aside from what you mentioned.

It would be nice to see midi to midi AI remixes, analogous to how Chat GPT can (sort of) turn wikipedia into rap lyrics.

Check the return policy on your laptop. You might still be within the return window!

Achronix | Santa Clara CA, Bangalore, Remote | Remote OK | https://www.achronix.com/ | Full time

We're a high performance FPGA startup of about 200 people. We compete directly with Xilinx and Altera with our Speedster FPGA products and we also sell FPGA fabric as an IP. One of our key differentiators is that we use a Network on Chip (NoC) architecture with Network Access Points (NAPs) throughout the fabric instead of at the edges. This allows for much faster designs and fewer LUTs used for routing data. We also have more granular partial reconfiguration zones and constrained place and routing for designs that have copies of certain components. As you might imagine, this requires a lot of smart engineers, and we're growing the team! Here's what we're looking for:

Software Engineers: C++, Java, Python, System Verilog

Hardware Engineers: Architecture, Design Verification, Physical Design

Careers page: https://www.achronix.com/company/careers

Recruiter contact: keithwhite@achronix.com

We're debt free, net profitable (over $100M/year) with cash on hand, and we're pre IPO. We have an established set of customers in many different areas of the market including Smart NiCs, AI, high frequency trading, and autonomous driving, and high performance computing.

One of the difficulties of open sourcing bitstream generation of an FPGA is not the fabric itself, but all of the other IPs on the chip. Things like PCIe, Ethernet, memory controllers, SerDes and whatnot are often licensed from external vendors who don't want their register maps out in the open. Some FPGA vendors give you a simulation model, but I'm pretty sure you have to sign an NDA.

Also IPs sometimes have errata in them that need to be worked around. With an FPGA, you can usually fix it in soft logic, but vendors don't like giving that out either.

For some smaller FPGAs without complex IPs, they are starting to open up their bitstream generation algorithms. Though bitstream generation is pretty trivial compared to synthesis and place & route.

Did Synopsys design the DDR5 controller by any chance?

Pretty much, but I'd change the dimensions of the graphics card to match mini ITX, and so that it could be bolted to the case. This provides two benefits: It can support a bigger and heavier heatsink and it also allows you to spread the VRMs around the chip and DRAMs for more consistent power flow.

> Should we have GPU VRAM slots alongside CPU RAM slots? Is that even possible?

I chuckled a little at this because I used to wonder the same thing until I had to actually bring up a GDDR6 interface. Basically the reason GDDR6 is able to run so much faster is because we assume that everything is soldered down, and not socketed/slotted.

Back when I worked for a GPU company, I occasionally had conversations with co-workers about how ridiculous it was that we put a giant heavy heatsink CPU, and a low profile cooler on the GPU, which in today's day and age produces way more heat! I'm of the opinion that we make mini ATX shaped graphics cards so that you bolt them behind your motherboard (though you would need a different case that had standoffs in both directions.)

While you're correct that overall system cost is what matters, most functionality is offloaded to the controller because a single controller often controls multiple DRAM chips (Like the chips all share a CA bus[1]) So it's cheaper to put the functionality in the controller.

With that being said, it gets a bit nuanced, because as we make faster and faster DRAMs, we need more complicated input/output electronics (Phy and ECC.) GDDR actually has self refresh as part of the spec and even allows DRAM vendors to put a PLL inside so you can run a half rate clock, which technically makes it "Quadruple Data Rate" instead of "Double Data Rate." But usually with GDDR, you're running one controller per DRAM. Clamshell mode is not super common in my experience.

[1] I'm not super well versed on DDR4 and all of its configurations. So someone who is can elaborate if they would like.

So this is really cool and useful, but it's important to keep in mind that since this is a diffractive structure, it probably only works with coherent light (what you get from a laser.) Most normal light sources produce incoherent light, and that tends to not work so well with complex diffractive structures.

I would imagine that you generate the desired transform function of a diffractive structure rather than the structure itself, because the structure is ultimately derived from the transform function. Since the transform function is basically a 2D fourier transform and a spatial frequency/phase plot, it's not _that_ computationally costly. Once you settle on functions you like, you then generate and or simulate a diffractive structure and see if it behaves how you expect.

Sort of, I didn't dive too far into the math, but it looks like each diffractive structure is akin a layer of a neural net, which is tuned for a set of spatial frequencies and phases, which when combined (like layers of a neural net) to form recognition of more complex objects.

There are a few gotchas in that statement though - for one, I didn't dive too far into the math, and I would assume that the convolutional algorithms as well as the underlying matrix functions may be different. But at the end of the day, you're approximating a complex function using an array of simple functions with different weights and scale factors. The other gotcha is that diffractive structures use monochromatic light, so it's probably not too useful in most normal situations with normal light sources.

This is really great, because it touches on the concepts of hardware design. I've thought a lot about this myself, and I'm honestly surprised to see someone else discussing this. Maybe I'm way out of my depth here, but the idea of stateful programming doesn't actually fall under the paradigm of sequential programming (think single threaded programming.) We all like sequential programming for the same reasons we like linear signal processing and euclidean geometry. When things break those paradigms, we of create mental models (transformation functions) to try to emulate it back in the linear world where the math is easier (for the most part, I'm not too well versed in those subjects. It's more of an analogy.) And I think that's what this language is trying to do, except for certain concepts of non-sequential programming.

Now I sort of disagree with the author when they state that no high level language exists for stateful programming, because a HDL (used for designing chips and programming FPGAs) is exactly this. Now is System Verilog a high level language? Maybe not, maybe the author is right.

Interestingly enough, a lot of hardware blocks (think like a ethernet controller) use a special purpose hardware based state machine to control and manage the link status. While this is less flexible and less programmable than a CPU (which is also a state machine at it's core,) it uses far less power.

You can think of a CPU as a state machine that can emulate other state machines (though that's probably not a great way of thinking of a CPU because it can do many other things.) However, an FPGA can do it far more efficiently, but it's a pain in the butt to program. Now I'm not suggesting we do everything on FPGAs, but as we start to run up against the physical limitations of speed and transistor density, I think it's good to think about other paradigms of computing and how we can more efficiently compute things.

Well I'll be...

Though the renderings indicate that this is a CXL controller connected to DRAMs on the back end. It makes sense, since the front end logic for CXL is die area intensive. This is basically an SSD without all of the complexity of wear leveling.

> The extra latency is estimated to be no worse than a NUMA hop

I was almost going to mention that in my previous comment and point out that this might be a thing in enterprise applications where SRAM is plentiful, but not likely to outright replace DDR in most consumer computing devices as the parent comment seemed to suggest.

Doubtful. PCIe Gen 5.0 x16 over DDR5 is a huge cost increase, a huge latency increase, and only a minor bandwidth increase (about double after accounting for protocol overhead.) At that point, you might as well widen your memory bus and use 2 DRAMs. The memory controller doesn't get much more complicated because both chips share a CA bus, and the DRAMs are cheaper. I don't work for a DRAM vendor, but I would imagine that the front end logic in the DRAM (the DDR controller inside the DRAM) uses way less than half the die area that a PCIe Gen 5.0 x16 EP would use.

I think there are a lot of misconceptions here in other sub comments.

For starters, the DRAM manufacturers may possibly be the biggest penny pinchers in the semiconductor business. They're too cheap to use differential signaling even on GDDR memory. I'm not saying that PCIe RAM is never going to happen, but as somebody who works with DRAM controllers and DRAM vendors, I can not fathom a world where DRAM manufacturers put a PCIe controller on each chip, especially one capable of Gen 6.0 speeds! The extra die area, complexity, and bringup testing necessary for a PCIe controller is insane

Second of all, the latency would really destroy system performance. The DDR protocol is designed to minimize latency (well kind of, there are still speed targets that need to be met.) The whole point of using a parallel bus with unscrambled data is to eliminate encoding/decoding latency. PCIe uses a Serializer/Deserializer (SerDes) that's scrambled on one end and then de-scrambled on the other end using a LFSR. It also goes through an adaptive tap filter. After that, the ordered sets from each lane are assembled and sent through a FIFO for clock domain crossing/timing recovery. All of those steps add latency to the system, and that's before we get to the Data Link Layer and Transaction layer. While I'm not well versed in CXL, I know that it shares the same Physical layer (a SerDes Phy.)

Now you might imagine a chip with one PCIe end point that fans out to an array of DRAM chips on the back end, and you don't care that much about latency. But then that makes PCIe RC and EP in the system redundant because you could put the DRAM controller where you would otherwise put the PCIe controller. Now it might make packaging easier and allow for a cheaper version of DDR to be implemented, but is there a net savings? and does it justify the latency hit? Maybe. I'm not saying it's never going to happen, but I wouldn't bet on that tech.

You can with enough money. Usually you see ground traces and ground planes separate high speed data buses. The problem is that the more layers you have, the more expensive it is.

The risk averse nature of the semiconductor industry comes from it's financial scale and speed. If there's a mistake, re-spinning the chip (even just the metal layer) is costly both in time and financially. No self respecting semiconductor company wants to be the guinea pig for an entirely new tool.

That being said, better tools for design and verification would still win out since developer time is more valuable/scarce than computational time. However, hardware tends to differs from software in that the computational requirements for designing and verifying a chip design are far greater than the average product in the software industry.

Literally everyone I know in my industry hates the current state of EDA tools, and fees like they're stuck in the past, yet most of them defend the use of Perforce over git, Cron over Jenkins, XML over JSON, TCL over Python, Cisco Any-connect over Tailscale, and running their remote terminals in a VNC session instead of using SSH like normal people. I feel like the pot is calling the kettle black here.

Fun fact: The dimensions of a magnet (a bit of data) on an HDD are actually rectangular. It's about 3-5x wider than it is long. This favors read/write speed, since you cover more bits per rotational length. Aside from the obvious speed boost you get from it, it's also done to make it easier to stay on track.

One of the huge limitations with bit width is the ability to keep the actuator arm stable within the 15 or so nanometers because of the air turbulence. That's why they fill the drives with helium now, less aerodynamic drag/turbulence means you can either cram more platters in (which increases the turbulence back to where it originally was) or make narrower tracks since you have more precision.

Not Paul Campbell, but I'll share what I know on the matter.

So GPL'd IO blocks - This is a great question, and something I have definitely been asking myself! One thing to keep in mind is that IO interfaces like PCIe, USB, and whatnot have a Physical interface ("Phy" for short.) Those contain quite a bit of analog circuitry, which is tied to the transistor architecture that's used for the design.

That being said, A lot of interfaces that aren't DRAM protocols use what's known as a SerDes Phy (short for Serializer De-serializer Physical interface.) More or less, they have an analog front end and a digital back end, and that digital back end that connects to everything else is somewhat standardized way. So it wouldn't be unreasonable to try to build something like an open PCIe controller that only has the Transaction Layer and Data Link Layer. While there are various timing concerns/constraints when not including a Phy layer (lowest layer,) I don't think it's impossible.

The other big challenge is that anyone wanting to use an open source design will definitely want the test benches and test cases included in the repo (you can think of them like unit tests.) Unfortunately, most of the software to actually compile and run those simulations is cost prohibitive for an individual, because it's licensed software. Also, the companies that develop this software make a ton of money selling things like USB and PCIe controllers, so I'll let you draw your own conclusions about the incentives of that industry.

Even if you were able to get your hands on the software, the simulations are very computationally intensive, and contribution by individuals would be challenging ...though not impossible!

Despite those barriers, it's a direction that I desperately want to see the industry move towards, and I think it's becoming more and more inevitable as companies like Google get involved with hardware, and try to make the ecosystem more open. Chiplet architectures are also all the rage these days, so it would be less of a risk for a company to attempt to use an open source design.

I'd really be curious to hear Paul Campbell's take on this question though. He definitely knows a lot more than I do!

I used it a few years back, but for me the color temperatures never scaled right. I like my lights at 4500-5500K during the day, but it looks a little too warm on my monitor (f.lux defaults daylight to 6500K.) Maybe it's my lights/monitor, but I really wish I could set different curves, or at least different color temperature targets for my lights and monitor. f.lux didn't allow me to do that. It only gives options for "warmer" and "a lot warmer," which both look weird at night. I ultimately hacked something else together, but it was a little disappointing, because I really like f.lux.

You know, it wasn't long ago that Blender was a somewhat obscure open source CG/3D modeling software that was not taken super seriously for enterprise use. Blender has been around for a really long time, and there has always been a community of users and developers who improved the software over the years. Eventually it hit some sort of critical mass where it got good enough, and attracted enough attention and funding to accelerate the development (I like to think this was the 2.8 release.) This started a positive feedback cycle where it got better, attracted more attention and funding, thus improving and polishing it even further to the point where it's sponsored by practically every major tech company, and taken seriously when compared to commercial software.

So I like to think that there's hope for FreeCAD or something similar. Especially when considering how the 3D printing/maker community has become increasingly prominent. There's definitely demand for open source 3D CAD and a passionate and capable community of makers willing to make that happen. But this type of software isn't built, refined, and polished overnight.

Yes, but assume that they're cherry picked. Don't get me wrong, these numbers are impressive, but it claims that it's GPU is faster than the highest end discrete GPU (RTX 3090) but it's unclear on what benchmark it used. It's important to keep in mind that their GPUs are not architected with gaming in mind, whereas the 3090 definitely is. So it's not unreasonable to find some metrics where their GPU performs better.