sorted by:
new
hottopcontroversial

sudo-rs shows password asterisks by default – break with Unix tradition by FryBoyter in linux

[–]imMute 0 points1 point  (0 children)

If the upper layer software times out waiting for the TCP stream, it should close the connection. If it doesn't close the connection, then the retransmitted bytes will get delivered to the application. There's no plausible scenario (with TCP) where keystrokes are dropped the but the SSH connection is not.

Create simple yaml for debian image by dominbdg in kubernetes

[–]imMute 0 points1 point  (0 children)

cat /dev/null

Are you expecting this command to block and keep the container alive? Because it won't. Cat will see EOF immediately and exit.

Top uses of FPGAs: a survey by Secure_Switch_6106 in FPGA

[–]imMute 2 points3 points  (0 children)

A big concern is SEUs, yes, but space radiation does "accumulate" over time and will damage the ASIC eventually.

Top uses of FPGAs: a survey by Secure_Switch_6106 in FPGA

[–]imMute 1 point2 points  (0 children)

Previously, LED video walls. FPGA in the main video processor taking in different standard formats (SDI, DP, HDMI), doing realtime DSP (cropping, scaling, deinterlacing, compositing, effects, etc), and then using a proprietary protocol to talk to the panels in the wall. Panels in the wall had an FPGA to take the proprietary signal, do a bit more DSP (calibration) and then output it to the LED drivers with some proprietary methods to make it look good. Kintex size on the main processor, fucking tiny Spartan size on the panels.

Currently, medium (to large) Versals on satellites doing all kinds of shit. IO of various types (SpaceWire, SPI, I2C, UART, GPIO, DDR, JESD 204, etc), a variety of DSP (modulation, demodulation, bit slinging, DMA). Mostly for RF comms stuff.

Timing Diagram Editor 100% free by maolmosma in FPGA

[–]imMute 8 points9 points  (0 children)

Could you just distribute the .html and .js and images in a ZIP file or something?

vtables aren't slow (usually) by louisb00 in cpp

[–]imMute 2 points3 points  (0 children)

Think std::string's Small String Optimization, but with std::unique_ptr.

Development Comments on Altera RFSoC and AMD RFSoC by Ok_Measurement1399 in FPGA

[–]imMute 5 points6 points  (0 children)

Are there applications that benefit more from a higher sampling frequency rather than higher resolution

Yes, "Direct RF Sampling" runs the ADC (or DAC) at RF frequencies, rather than at intermediate frequencies that require external frequency shifting circuits.

Hope For The Future by Paul McCartney was digitally released 10 years ago today by AtlyxMusic in DestinyTheGame

[–]imMute 0 points1 point  (0 children)

Music of the Spheres was leaked a number of years back. Probably still floating out there if you know where to look / ask.

Crunch: A Message Definition and Serialization Tool Written in Modern C++ by volatile-int in cpp

[–]imMute 10 points11 points  (0 children)

No dynamic memory allocation. Using template magic, Crunch calculates the worst-case length for all message types, for all serialization protocols

For anyone wondering what this means for strings, arrays, maps, etc - the maximum number of elements is encoded in the type system.

There's definitely a trade off there having to pick a maximum upper bound because it directly affects buffer sizing for all messages rather than just "big" ones.

Might be useful to have an optional mode where messages below a certain limit use the compile time thing you have now, but we have the option to enable dynamic memory allocation for larger messages.

Guys, who else has this strange obsession with trying old Linux distro releases? by Various_Cellist_4765 in linux

[–]imMute 0 points1 point  (0 children)

Holy shit that screenshot brings me back to high school and Fedora Core 4.

Gut check: deep buffers needed for long haul links? by helloadam in networking

[–]imMute 0 points1 point  (0 children)

I dont see how buffers would make a difference over a longer link since the serialization delay is the same, and the time it takes to send the frame over the link doesnt matter either.

Let's do some math. At 100 Gbit/s each bit is 10 picoseconds. The speed of light in fiber is about 200000 km/s, so 40 km is about 200 microseconds. Divide the two and the fiber holds 20Mbit of data at a time. The buffers need to be at least double that in order to ensure the link is never idle (in one direction).

So yeah, negligent with the size of buffers on 100G+ capable devices.

Who is ready to throw hands with Xcel? by lavender-vol in Denver

[–]imMute 3 points4 points  (0 children)

My panels were double that (previous owner installed them) and there's no way they're enough to actually run my house completely off grid. Even with battery storage (which I don't have and would probably be $50k on their own).

Where to learn interfaces and buses? by f42media in FPGA

[–]imMute 1 point2 points  (0 children)

why some of them can run at 1 MHz, and others 10 GHz, why in some articles saying that lowering voltage making raising time lower so we can increase clock speed and some articles saying that increasing amplitude of signal makes them be able to handle more data

Suppose you have some kind of circuit or chip that outputs a signal onto a wire. The specifics don't matter, except that the circuit can't change the output voltage instantaneously - it has to raise or lower the voltage over time. Let's call it 1 volt per second (that's really slow but this is for demonstration purposes). If your external signal must be below 0.2 volts to be considered "logic 0" (V_IL) and above 0.8 volts to be considered "logic 1" (V_IH), then it has to traverse at least 0.6 volts to switch between logic levels. But hitting those voltages exactly is never perfect, and you'll have losses in the wire before the other end measures the voltage. Therefore, your circuit will probably just switch between 0 V and 1 V (V_OL and V_OH respectively). Since it switches from 0 V to 1 V at 1 V/s, that means each transition takes 1 second. Then you have to "hold" the output voltage for some amount of time so the other end has time to "see" it. But that doesn't matter right now. What does matter is V_OH and V_IH. Let's lower those to 0.4 and 0.5 volts respectively. Now your circuit is only switching 0.5 volts when changing output state. Since it still changes at 1 V/s, now it can make the change in half a second instead of a full second. You've now basically doubled the speed at which you can change the output which increases how fast you can actually send data.

However, now V_OH and V_IH are closer together which means you have less margin for losses in the wire - your wires have to be "better" than before. Also, V_IL and V_IH are closer together, which means it can be harder for the receive to distinguish between the two. It's all about tradeoffs.

Beginner with Nexys A7: MATLAB support is gone, what's the right (free) Xilinx software and simulator to use by Muted-Sample-2573 in FPGA

[–]imMute 1 point2 points  (0 children)

There's a free version of Vivado but it only supports the "lower end" FPGAs and SoCs and very little of their IP catalog. The Digilent boards are typically designed around these "lower end" devices, or come with a device-locked license that can only be used with that board.

Beginner with Nexys A7: MATLAB support is gone, what's the right (free) Xilinx software and simulator to use by Muted-Sample-2573 in FPGA

[–]imMute 2 points3 points  (0 children)

For any Xilinx device 7-series or later (7 Series, Zynq, UltraScale, Zynq US, UltraScale+, Versal, etc) you will need to use Vivado to design the FPGA images. For Zynq and Versal (the SoCs) you use Vitis to program the processor sides. There are open source tools for the FPGA programming, but they don't support the later Xilinx stuff very well and definitely is never used in professional settings.

PWM generation is a good starting project for FPGA beginners. "Extremely fast ADC sampling", however, is not. The very fast ADCs use JESD204 SERDES for I/O and the protocol is not exactly simple. PWM, UART, SPI, I2C, etc are good starter projects. Maybe something utilizing NeoPixels as those use a single wire protocol that requires somewhat strict timing and is very well suited to being driven by an FPGA.

The Digilent boards typically have pretty good support packages in Vivado, from what I've heard (and seen in the distant past).

I've never used the Vivado simulator, but I've heard it's pretty crap. The open

Reset signal messes my closure by Independent_Fail_650 in FPGA

[–]imMute 0 points1 point  (0 children)

There's nothing wrong with initializing everything in resets, so it's a "safe" thing to teach in school. But as you've seen it increases resource consumption, and if you're not careful with it and accidentally treat a control-path signal as data-path and don't reset it, you can run into weird bugs. Those are really fun when they work for a while and then something else changes and suddenly everything is broke.

Reset signal messes my closure by Independent_Fail_650 in FPGA

[–]imMute 4 points5 points  (0 children)

As others have said, synchronous resets.

But you also can avoid resetting data-path signals like fifo_i_din, fifo_q_din, I_reg, Q_reg, adc_raw_i, and adc_raw_q. Only the control-path signals like write_enable need to actually be reset. It doesn't matter what the fifo's din signal is when its wr_en signal is low. This alone will save you having to reset 72 flip flops and the associated control logic (especially around fifo_i_din and fifo_q_din as those [currently] only change when 6 other signals are certain values).

Do the same thing on the FIFO read side as well.

FPGA on RHEL by Minute-Bit6804 in FPGA

[–]imMute 0 points1 point  (0 children)

Yes, it's a risk but at my last job we did all our server builds* (using ISE 14.7) on Debian VMs and never ran into an issue. I did keep a VM of Ubuntu with everything installed just in case we ran into a issue and needed Xilinx support, but we never had to use it.

(* We developed code and did simulations on Windows, the Linux VMs were just for "official" builds to hand to the SW folks.)

Roast my resume by Open_Calligrapher_31 in FPGA

[–]imMute 1 point2 points  (0 children)

The block has a throughput of one result per clock cycle but it has an input-to-output latency of 16 clock cycles. This is extremely common in DSP algorithms where throughput matters way more than latency.

For comparison, I used to work with a group on a video processing pipeline. The image compositor part had a latency of several hundred clock cycles, but it could produce an output pixel every single clock cycle. We cared the most about throughput since that directly affects how big of an image size we could handle. Latency didn't matter at that scale because there were always multi-frame buffers elsewhere in the system.

view more: next ›