mng2

They mention APIs for Windows, Linux, OpenSolaris, a ZLIB, and the Apache module.

http://www.aha.com/DrawProducts.aspx?Action=GetProductDetail...

The article mentions designs where the muons can circulate 2000 times, so I think this publication is assuming some conceptual knowledge on the part of the reader.

Muons are generally produced by hitting a target with a beam of something else, so they will not be born at rest. The problem is that making a beam this way is somewhat "splattery" and the resulting components of velocity will not be 100% down the beam path. These perpendicular components need to be removed as much as possible, a task which is referred to as "cooling". Muon cooling is still in its infancy. My friend did his PhD on the project mentioned in this article: https://www.nature.com/articles/d41586-020-00212-3

Very interesting stuff. I wonder, did you try -1 (0xFFFFFFFF)?

It's interesting to consider the N64 in contrast to the first Voodoo card. One is a console and the other is an add-in card, but both launched in 1996, with underlying 3D technology from SGI. The Voodoo used EDO RAM, 8 chips of 256k x 16b, 2 MB for the z+framebuffer and 2 MB for the texture memory. With 50 MHz EDO RAM, wired in a 64-bit bus, the peak texture bandwidth would be 400 MB/s, dedicated to that purpose alone; in contrast the N64 RDRAM was main memory and had to service other functions.

The N64 launched at $200, the Voodoo at $300. Of course you would additionally need a computer to run the Voodoo, but I remember thinking the N64 was already way too expensive back in the day. It would've been even more expensive to support a 64-bit memory bus.

The person you're responding to probably worked with DSP chips, which are generally not floating-point. e.g. Motorola 56000, TigerSHARC, Blackfin.

Thanks, looking forward to reading more. I am a hardware guy, but I see using higher-level languages to generate HDL as being a very powerful approach.

Great stuff, cool project. Could you share a few thoughts on your language and transpilation approach?

Wow, the Z1C is pretty old. Do you have any trouble with battery life?

I used to run a Z3C, but after some of the seals got loose I upgraded to an XZ1C. It's near perfect for me, and I don't know where I'm going to go next for a compact phone.

I used to be bothered by reconstructions, especially ones rebuilt in the 20th century. But since then I've realized just how fragile and transient buildings can be, and how much effort it takes to maintain the ones we've got. If it takes modern rebuilding to bring back the experience of being in or near a unique piece of architecture, then that's better than the alternative.

I spent some time looking through the NTSB docket today. I was a little surprised that Apple was willing to provide logs from a development model iPhone. Evidence seems to point to the victim playing a game while commuting -- in my opinion this is a major indictment of Tesla's approach to self-driving, where the user is lulled into a false sense of security.

Another docket was updated today, a Tesla crash in Florida eerily similar to the one a few years ago: semi turning across the highway, Tesla goes under the trailer. Not a great failure mode.

Did they tell you exactly where it blew up? Then it might be fair, 2 pages is not that big. Though you'd still be at quite a disadvantage compared to someone who spent a lot of time designing the thing.

I gotta say though, if they themselves designed this board that promptly blew up, perhaps they should recalibrate their expectations for EEs.

I had to replace the switches in my G100s after a few years, first the scroll wheel button and then the left click. Definitely an unacceptable level of longevity.

"High Speed Digital Design" generally refers to PCB level design. The Black Magic books are pretty old, covering ancient stuff like DIP packages on manhattan-routed boards. These days the keyword is SI/PI (Signal Integrity, Power Integrity).

Even a fabless semiconductor company (e.g. nVidia, Apple, heck, AMD) needs to spend hundreds of millions to tape out a leading-edge IC. It's a capital-intensive business, and would present quite a risky bet for any upstart competitors. Also, patents.

https://semiengineering.com/big-trouble-at-3nm/

Most American whiskeys require new charred barrels, corn whiskey being the most common exception.

See pages 21-24: https://www.ttb.gov/images/pdfs/whisky-webinar.pdf

Here's a greatly simplified example. Let's say you're trying to calculate y = mx + b in your FPGA. You want this operation to run at 100 MHz. Great, you write the code, synthesize and implement. Uh oh, the tools report that your design has failed timing analysis. What now?

Looking at the output of the tools, they'll say something like "x to y setup time: -2 ns slack". That means your desired operation can't meet the 10 ns clock period; it actually takes 12 ns for all the logic to ripple through. So now what?

You can break up the operation into two steps. Let's say the multiplication takes 8 ns, and the addition takes 4 ns. In timestep 1 you do z = mx, and pipeline c = b. Then in timestep 2 you do y = z + c. This way your operation takes two clock cycles = 20 ns total in terms of latency, but you can maintain a rate of 100 MHz.

Alternatively, you could choose a slower clock rate, say 75 MHz, and have a clock period of 13.333 ns. Then you would be able to meet the logic delay requirements in one cycle.

Again this is greatly simplified but it's similar to what one ends up doing in real FPGA designs. At the beginning you're usually trying to achieve maximum performance. Then later on you add more features to the FPGA, only to find that in doing so, you've caused an existing portion of the design to fail timing, so you need to twiddle things around.

I'd be curious to see what shorting across the transistor would do. It would probably reveal whatever behavior they wanted to avoid.

Wow, that was quick. Given that this is Broadcom, I don't suppose there is any visibility into the Root Complex? When troubleshooting PCIe it'd be nice to have the LTSSM state at least. Would be really cool to get eye diagrams...

So I think you don't need to measure the capacitance per se. Instead you use the capacitances to make a series of (AC) voltage dividers. The lines that are individually broken out (call these the vernier lines) will have different degrees of coupling to the sense node, depending on the caliper position. Assume the capacitance of the sense node is fixed. The controller pulses each vernier line in sequence and measures the sense node in turn. The higher the capacitance of a given vernier line, the more voltage will couple across to the sense node. The highest pulse tells the controller which vernier position it's in, so the absolute voltage levels don't matter, conceptually speaking.

As for the distance between plates, a caliper ought to be made to a high degree of repeatability. PCB thickness not so much though, probably 10%? To first order capacitance goes as ~1/d. But again, the measurement is relative, not absolute. As long as all the capacitances are affected by the same distance factor, the scheme still works.

Anyway, that's an informed guess based upon those scope shots.

If you've not been previously exposed to stuff like Lagrangians and Hamiltonians, I'd suggest Taylor's Classical Mechanics text, which is quite friendly.

When you say the power was cut to your USB keyboard, could it perhaps have been reset and in a unenumerated state? If you have a multimeter it could be useful to check the various power rails in the bad state.

Try running Memtest86 and lower the temp while it runs.

I went from Z3C to XZ1C last year when the rubber on the USB cover piece stopped working right. After getting used to the look, I like it a lot. It's a more physically solid design.

That SoM is well within KiCAD's capabilities. Layout is not the issue. The fraught part is designing the DDR4 interface -- a pro shop will pay out the nose for a signal integrity tool like Hyperlynx to do simulations. While in theory you could write your own sim tool, or somehow respin your way to working boards, I think either approach would be a challenge.

At my work we use a COM Express module that has a Potato Semi part on it. Gotta wonder what the backstory is on that company.

The point is you are limited by the capability you build in at launch, SDR or otherwise. The hardware side is more restrictive than the software side.

That really is the elephant in the room where SDR is concerned (along with front-end). More realistically you could change protocol/encoding after launch.

Yes, the EIC is much more about nuclear structure than traditional particle physics.

https://en.wikipedia.org/wiki/Deep_inelastic_scattering

Absolutely, arsenic-containing materials have the potential to be extremely dangerous. Unscrupulous GaAs manufacturers have put their employees at risk in the past.

[0]: https://www.eastbayexpress.com/oakland/the-axt-way/Content?o...

The Snickerdoodle got a lot of attention for its price point (which turned out to be unrealistically low... I commend them for following through though). It's an odd platform. They were going for an ecosystem of carrier boards, but ended up with 0.050" pitch connectors. Which are good if you've got flying leads, but I can't see myself using a Zynq for that kind of work. The mating connectors are ~$7 in small quantities which is comparable to the smaller, tighter pitch connectors other dev boards use, so there isn't really a cost savings if you build your own plug-in boards. It might even cost more for wide I/O in terms of connectors and board space.

You're right that technology has continued to march along. $250 for a Zynq Ultrascale is very tempting, but I have enough dev boards collecting dust...

To be fair, specs and standards generally aren't written as introductions, so they're kind of hard to make sense of when starting from zero. USB, with its infernal descriptors and endpoints, benefits mightily from third-party explanations.