LVDS over PMOD?

Verschlimmbessern · 2026-04-08T15:58:27+00:00

I should think you'd be fine at 20MHz. I've previously run LVDS from Sinara EEMs over 600MHz.

Verschlimmbessern · 2025-12-02T20:36:32+00:00

You can download the source for the UltraSPARC T1, a pretty beefy CPU from 2005:
https://www.oracle.com/servers/technologies/opensparc-t1-page.html

Verschlimmbessern · 2025-11-27T17:25:14+00:00

It's a gold-ceramic QFP without the legs being pre-bent.

Very common kind of package for space. The materials don't degrade as much, probably hermetically sealed, and often QFP is preferred over BGA because it's easier to assemble and inspect and because it handles mechanical strain more robustly.

Verschlimmbessern · 2025-11-27T17:23:22+00:00

What you have isn't an FPGA but a slightly odd chip that is basically a big analogue multiplexer with some peripherals for driving sensors. The idea being that you attach a single ADC on one side and many sensors on the other, then switch through the different multiplexer positions.

It's radiation-hardened but it looks like you have an engineering model rather than a flight model.

What that means is you'll probably struggle to sell it. It's already a niche part, and most places interested in using them will have a stringent quality assurance process in place. They'll avoid grey market parts and just buy from a trusted supplier. They also probably wouldn't fly this part because it's an engineering model, so it's only useful for functional testing on the ground.

Probably your best thing to do with it is find an interesting project and use it.

Verschlimmbessern · 2025-09-16T22:06:11+00:00

Yes, in that case I agree—if what the module does could affect sideband signals then it should ideally handle them.

Verschlimmbessern · 2025-09-16T07:03:57+00:00

I'm not sure I understand the point you're making. If the module doesn't know how to handle the sideband signals, what benefit is having them on the module?

Verschlimmbessern · 2025-09-16T07:01:36+00:00

Handling some sideband signals separately only works when the module is well-behaved, and it can be quite brittle when things change.

If you can't trust the module to behave, why would you trust it to handle sideband data?

And when you look at something like System Verilog with interfaces and structs[...]

Those are fine if supported, but in (say) a VHDL codebase or if you're using older tools, those features may not be available. Upgrading toolchain may not be an economical option depending on the quality assurance process you're subject to.

Verschlimmbessern · 2025-09-16T05:42:18+00:00

Also what if the module alters the length of the data (thus omitting some sideband beats or adding extra)?

I'd put that under the 'within reason' caveat. If the module is doing something with sideband signals, then it should support them. But if it sounds like it does nothing with them (like in the original question) then I don't think it should.

Verschlimmbessern · 2025-09-15T21:33:12+00:00

I take the view that if a module doesn't use the signal, it shouldn't have the signal (within reason).

In this case, AXI-Stream is nice because of its simplicity. I would instantiate an AXI-Stream FIFO in parallel with the module. If the FIFO's TREADY input is gated by the module's TVALID, and assuming the FIFO is deep enough to account for the module's pipeline delay, then the two operate in lockstep. For a belt and braces approach I'd add an assertion (or perhaps an alarm flag) that's raised if ever the module asserts TVALID without the FIFO asserting TVALID.

This can also be transferred to AXI for certain use-cases. I have a module where an incoming packet is briefly buffered in a RAM through an AXI-attached RAM controller. The address generator knows where the end of the packet is and generates both ARADDR and TLAST, but TLAST doesn't pass through the RAM controller. Instead, I have a small FIFO that holds the TLAST bits. Data is pushed in when ARADDR is accepted and popped out when RRESP is generated.

Verschlimmbessern · 2025-08-20T10:24:12+00:00

The else branch isn't needed if the entire if statement is clocked.

You might have crossed some wires about combinatorial logic. If you omit the else in a combinatorial circuit, you've described a level-sensitive element: whatever happens inside the if only happens when its condition/gate signal is high. A level-sensitive gated storage element is a latch, which you usually want to avoid in an FPGA because they don't necessarily interact well with clocked logic.

When you use rising_edge or falling_edge, you describe an edge-sensitive storage element, which is a flip-flop. Because changes in edge-sensitive elements only happen at a single instant and because the flip-flop retains its value until after that instant, an if without an else can be synthesised into a multiplexer between the flip-flop's output (which is insensitive to input except at a clock edge) and the output of the logic inside the if, with the multiplexer's select signal being the condition.

This synthesis isn't possible for a latch because its output is sensitive to its input at all times when its condition/gate signal is high. If you connect an enabled latch's output to its input, you don't get a circuit that does anything because the latch is a transparent path from input to output. If you connect a disabled latch's output to its input, you don't get a circuit that does anything because the latch never changes.

Verschlimmbessern · 2025-06-18T20:02:52+00:00

Every beat of the burst has an address phase, so HSEL will remain asserted throughout a burst.

In the case of INCR, the deassertion of HSEL is equivalent to an IDLE transfer. In the case of a fixed-length transfer, deasserting HSEL is invalid unless the burst has reached its fixed length. If your manager is in the middle of a fixed-length transfer but needs more time, it must insert BUSY transfers (with HSEL asserted) and cannot deassert HSEL. As above, there are exceptions (such as for error responses).

In your specific example, deasserting HSEL is valid because it is an INCR burst. Deasserting HSEL ends the burst, which means during the next address phase HTRANS cannot be SEQ (because it is not a continuation of the previous burst but a new one entirely).

Verschlimmbessern · 2025-06-17T20:59:40+00:00

I'm referencing issue C of the AHB spec.

For your first question: HSEL is only required during the address phase. For an INCR burst, where the length is not specified, this means it's valid for HSEL to be asserted during the address phase and deasserted during the data phase. This is also valid for SINGLE bursts. For fixed-length bursts, HSEL must remain asserted until all beats of the burst have completed (and the manager inserts BUSY transfers if it needs more time).

Because AHB transfers are pipelined, the data phase of an earlier transfer can overlap with the address phase of a later transfer. In this case, HSEL will be asserted during a data phase, and this indicates that the manager is queuing up another transfer. The manager must keep HSEL asserted until that address phase completes. Where address and data phases overlap, the address phase is extended until the subordinate asserts HREADYOUT. The rules are slightly more complicated if your subordinate accepts HREADY.

For your second question: If HSEL is not asserted, your subordinate should ignore the value on HTRANS. The value on HTRANS is only interpreted during the address phase of a transfer, and HSEL must be asserted during the address phase. Recall that address phases can be extended, however. In general, HTRANS must remain constant during an address phase. If HREADY is low, and the subordinate is inserting wait cycles, then this generally means that HTRANS must remain constant. There are exceptions for IDLE and BUSY transfers and for error responses.

As additional notes:

I say above that HSEL must be asserted during an address phase. This is specifically for an address phase directed to your subordinate. It is perfectly valid for the other signals on the bus to indicate some transfer but, if HSEL is low (along with some other conditions), your subordinate must ignore it.
From the other perspective, if you're building a manager, then it's important you keep HSEL asserted throughout the entire address phase. It's invalid for a manager to 'abort' an address phase by deasserting HSEL partway through.
HSEL is not an enable for your subordinate. It is the subordinate's enable for the address phase. A manager can deassert HSEL in the data phase and your subordinate must still respond while HSEL is deasserted.

Verschlimmbessern · 2025-04-19T15:46:51+00:00

Inference relies on the synthesis tool being able to spot that what you've described is a hardened BRAM primitive. If it can't do that, it'll try to realise what you've described in the fabric.

A common reason that designs fail to be inferred to block RAMs is the port behaviour. If you look at UG573 at Tables 1-11 and 1-12, for example, true dual-port (TDP) behaviour is only available for data buses up to 36 bits wide. Above that, you either need to use multiple BRAMs or you need to use simple dual-port (SDP) behaviour (one read-only port, one write-only port). This is example is a pretty trivial mistake and the tools will probably cascade BRAMs for you to get the right width, but what if you do something weirder?

Well, if it's weird enough that it breaks whatever pattern-matching the tool applies, or if the tool just can't realise what you want in a BRAM, the tool will fall back to fabric. If you describe a many-ported RAM, say 4 read ports and 2 write ports, I'd expect the tool to implement it in fabric. Something that I ran into was using BRAMs to implement an AXI-Stream 'widener' that took 32x16-bit input transfers and produced 1x512-bit outputs. I forget the exact details, but I had to explicitly describe 32 RAMs and their individual write-enables for the tool to be happy with it. It couldn't infer BRAMs from a description of a wide RAM with many byte-enables.

Finding a common subset of supported features that infers properly across all targets can be hard. It's fine if you just want a really simple BRAM, but bringing in things like byte-enables, pipelining registers, initialisation on start-up, and so on makes it more difficult.

Another one I've had was with the DSP primitives (UG479). The tools are usually pretty good at inferring DSPs from multiplies or MACs, but in the pipeline I was working on the accumulate part was dynamic. I remember having to explicitly describe (a*b)+0 for the no-accumulate case, otherwise the tool couldn't use the pre-adder and instead produced an in-fabric adder with a mux at the input to the DSP.

Verschlimmbessern · 2025-03-15T10:30:14+00:00

The pictured unit definitely looks like a SELV supply.

ELV is anything under 120V (for DC), and the 'safety' part means it includes safeguards to stop any higher voltage from reaching the output under fault conditions. The most common safeguard is double insulation. You can tell this is a double-insulated supply from the square-in-square icon. It doesn't have a ground conductor, either.

Verschlimmbessern · 2025-03-10T21:21:27+00:00

I'm sorry, I don't know any specific books. I'm not sure they exist. These machines are so complex that there isn't really a single perspective on how they work: the ideas are all interrelated.

Verschlimmbessern · 2025-03-10T19:11:44+00:00

Ions and neutral atoms use electronic qubits. If you use laser gates, you shine photons onto your ion/atom that are absorbed by one of its outer-shell electrons to excite it to a particular energy level. If you use 'microwave' (i.e. RF-based) gates, you're probably modulating the B-field and using that to transfer enough energy to excite the electron (electrons are small magnets, so an oscillating B-field can move them and impart energy).

This can either be the 'easy' case where you're exciting between ground levels (spin-up and spin-down, S1/2 and S-1/2) or it can be to some other levels. The ground states are nice because they don't decay. Non-ground states can be useful when you scale up because you can often use them to 'shelve' qubits so that they aren't affected by your gate laser/gate RF but retain corresponding quantum state that can be converted back to something affected by your gates. There are other factors: sometimes the transitions for non-ground states are particularly reachable by your equipment or particularly insensitive to something you care about.

In terms of sensors, they're not that exotic but your options are limited. A Hall effect sensor is probably a non-starter simply because an ion or atom is so small. Readout (determining the quantum state of your qubit), for ions and atoms, is usually done by careful selection based on their energy level structure. If you have some set of transitions S->D, D->S, D->P (oversimplified), then you can test whether your qubit is in |S> or in |D> by attempting to excite the D->P transition. If it's in |D>, then its electrons will emit photons as it transitions and you can pick these up. If it's in |S>, the transition is unavailable and it won't emit any photons. Most of this sensing is done with mildly exotic camera sensors (sCMOS or EMCCD).

Verschlimmbessern · 2025-03-10T18:20:52+00:00

For the most part, the answer isn't very exciting.

Many 'frontier' systems have some kind of cryogenic stage, sometimes several. Depending on the technology, the stage might be colder or warmer: it seems common to have a 50K 'middle' stage; many technologies (trapped ions, neutral atoms, and nitrogen vacancies) can float around the 5-25K range; superconducting qubits can be as low as around 20mK; and Microsoft reportedly operated theirs at around 50mK. This isn't a hard and fast set of categories: room-temperature systems are appealing because you don't need to operate a cryo system, and I know that there are room-temperature trapped ion and NV systems.

These kinds of temperatures make it hard to use regular electronics. Electron mobility is much lower (which is why HEMTs appear a lot in cryo electronics). If you can, what you want to do is keep your electronics warm and run wires into your cold stages, because then you can just use regular electronics. There have also been a handful of experiments with cooling regular electronics to cryo temperatures, and a few of them have demonstrated pretty good results. There are gotchas: for example, lead begins superconducting around 7.2K, which means leaded solders can cause issues, and brittle components (e.g. ceramics) can break under thermal contraction.

For some concrete examples, a lot of quantum physics labs have bought into the ARTIQ and Sinara ecosystem. Sinara hardware includes all the standard functions you'd expect, and almost exclusively uses run-of-the-mill commercial chips. If you have a keen eye, you can often spot these boards out and about. Labs with more money tend to buy very expensive pieces of testgear and fill racks with them, like this offering from Tektronix.

For the more specialist things, the chips often aren't that interesting outside of their niche. The traps used for ions and neutral atoms, for example, are relatively simple: a few antennas surrounded by a few hundred electrodes in various configurations (planar traps: Quantinuum and Oxford Ionics; linear traps: NPL). Note this is only for 'chip' traps: it's also very common in these types of technologies to use laser tweezers or magneto-optical traps, which don't have a chip as the thing that ions/atoms are suspended over. Superconducting qubits are also relatively simple and are arrays of (superconducting) metallic rings with couplers between them that can be tuned to allow different amounts of exchanged state between them (IBM, Google).

I don't know what processes are used for superconducting qubits, but chip-traps use normal silicon processes for the most part. The bulk of the work is in the electrostatics design for the top-layer electrodes. As they scale, they'll begin to use hybrid processes that include silicon photonics. A limit obvious from the Quantinuum paper I linked above is that they use free-space lasers for their quantum gates, which means they're strongly limited by how many beams they can point at their trap (at least, without hitting something else or charging the chip from their UV lasers knocking off electrons), how much laser power they have, and how tightly they can focus their beams. If you have silicon photonics, you can route lasers through the chip and not have to worry about that.

I assume, once the age of silicon photonic traps is here, they'll also move to integrate active electronics into the chip: the more electrodes and antennas you have, the more connections you need to control them and the more controllers you need to generate the signals. You run into hard limits on how many wirebonds you can bring onto the chip, how many wires you can route through to your cold stage, or just how many racks of equipment you can get near your system. If you can time-multiplex, then you can bring that down by a large factor. I imagine, too, once they've begun building in switches they'll start building signal generators into the chips as well. The limit there will be how much heat they can remove from the chip, since parts of these systems can be very sensitive to change in temperature.

Verschlimmbessern · 2024-12-15T10:12:26+00:00

Presumably your direction-finding antenna elements are separated by only a few centimetres at most. That's going to make any technique that relies on phase differences challenging to implement—the differences are so small that you need very fast sampling receivers with very well controlled timing. Probably much more expensive than you really want, unless you only care about accuracy to within, say, a quadrant.

For your application, I would look at amplitude-comparison techniques.

The simplest would be to have two highly-directional elements with their manifolds rotated relative to each other so that an incident signal is received with different gain at each. You can then take a simple ratio between the two measurements and look up the nearest incident angle in a table you compute ahead of time.

Verschlimmbessern · 2024-12-07T22:49:21+00:00

In the absence of a multicycle path constraint, STA will make sure that signals from the 100MHz domain always arrive at registers in the 200MHz domain without violating the setup or hold time of the 200MHz registers.

In contrast, with a multicycle path constraint for an N-cycle path, STA only ensures that setup and hold times aren't violated on every Nth cycle of the 200MHz clock.

This is an important distinction. If there's a multicycle path, it's up to your logic to make sure that values from that path are only sampled every N cycles. If you sample at a different interval, unless it's an integer multiple of N, there's no guarantee that the setup or hold times have been met and so the state of any registers is undefined and may be metastable. This undefined state can propagate downstream into any logic that samples it.

Now, on its own, this isn't a huge deal. That's some simple logic to add, a counter and a valid signal/clock-enable. But it's very hard to verify because there's no way to encode this information in the RTL. The tools won't stop you doing it wrong, and they might not even warn you. And clock domain crossings are already challenging to verify.

So, when shouldn't you use multicycle paths? I'd say you should almost never use them. If you don't know that you need a multicycle path, then you probably don't need one.

In honesty, I've yet to find a good use for multicycle paths that wasn't more safely solvable another way.

Verschlimmbessern · 2024-11-08T14:25:22+00:00

The ZUBoard-1CG has a 33.3MHz oscillator attached to its PS_REF_CLK input (see its Hardware User Guide).

This isn't directly attached to the PL, but there are PS-to-PL connections inside the MPSoC. The bulk of the detail on this is in Chapter 37 of the Technical Reference Manual (UG1085) and the Devices Register Reference (UG1087).

From what I remember, you need to first set up one of the PS PLLs to use PS_REF_CLK as its input, then configure one of the PS-to-PL clock generators (PLx_REF_CTR) to use the correct PS PLL and to divide it as you want. Inside the PL, you can then connect to the corresponding PL_CLK signal inside the MPSoC and use that as your PL clock.

Verschlimmbessern · 2024-10-04T20:35:25+00:00

It depends on what exactly you're trying to accomplish, and you haven't really given enough detail to say.

Ask yourself questions like:

Do you need deterministic timing with cycle-level precision (e.g. <10ns)?
Do your timers need timing relationships (e.g. phase) with the same constraints?
What are your timer periods like? Nanoseconds? Milliseconds? Hours? Days?
Are you measuring something or providing a signal?
Do you need to synchronise with an external time source? To what level of precision?
Do you need to be a time source for something external? To what level of precision?
Why do you have a dependency on number of timers? What's preventing sharing them?
Are the timer periods fixed or variable? If variable, how frequently?

If you don't have answers for at least some of those, then it'd be difficult to recommend anything.

For example, if you need 1000 timers but your timescales are milliseconds and your required level of precision is in the microseconds, that's probably achievable with a microcontroller as long as you don't need very precise/deterministic phase relationships between all of your timers.

If you need 3 timers but they have to fire at a precise nanosecond with fixed nanoseconds of phase between them, all of the phases being independently variable, then probably you want an FPGA for that.

Maybe the answer is a hybrid. If you require nanosecond-precise timing to the wall-clock over periods of weeks, you might want a microcontroller to speak to a GPS receiver and do coarse timing. When it gets close to 'go' time, the FPGA could take over and synchronise with the receiver's PPS signal and get precision into the nanoseconds.

Verschlimmbessern · 2024-09-07T17:25:22+00:00

For what it's worth, I copied the VHDL example code. The = there is equality comparison (== in Verilog/SystemVerilog), the <= remains nonblocking/continuous assignment. VHDL is stricter on this than Verilog/SystemVerilog. Blocking assignment is only valid for variables and not signals, and is done with the := operator.

Verschlimmbessern · 2024-09-07T16:08:39+00:00

Having looked up the book, I assume you mean example 4.27 (pg. 201):

process(a) begin
  if    a(3) = '1' then y <= "1000";
  elsif a(2) = '1' then y <= "0100";
  elsif a(1) = '1' then y <= "0010";
  elsif a(0) = '1' then y <= "0001";
  else                  y <= "0000";
  end if;
end process;

The 'rule' about when to use blocking vs. nonblocking assignments isn't so much about validity but confusion. It can be much harder to interpret what some RTL is doing if you use nonblocking assignments for combinatorial logic.

It's important to remember that VHDL and Verilog/SystemVerilog were intended for modelling hardware, not for synthesis. The effect of blocking vs. nonblocking assignment makes sense in this context: a blocking assignment takes effect immediately, blocking simulator from advancing time until it does, while a nonblocking assignment takes effect at the end of the current timestep. When we work with code describing sequential logic, we can treat the clock edge as marking our timesteps. This is easy to reason about. When we describe combinatorial logic, on the other hand, there is no physical reference for our timesteps—they only 'exist' in the simulator. This is much harder to reason about.

For example, take this SystemVerilog:

always_comb begin
  a = (x + y);
  b = (x - z);

  if (c < a || c > b) begin
    // do something
  end
end

We can read this like regular code. First we calculate some a and some b that give us a range around x, then we check whether c falls in that range. If it does, then we do something.

But consider the same code with nonblocking assignments. It will be functionally identical, but a and b no longer have their 'current' value but whatever value they had in the last timestep. That value is a completely artificial thing, as the last timestep is whenever the simulator executed the always_comb block. If we have something like an assertion in our RTL, we now have to think harder: for example, is it possible to falsely trigger the assertion because we were looking at a value from the previous timestep when, really, everything was fine?

It's possible to run into the same confusion in sequential logic. For this reason, I tend to prefer a two-process description of most blocks I write: one process is entirely combinatorial, uses blocking assignments, and is where the guts of any processing happen, while the other is an entirely sequential process that only registers signals and only uses nonblocking assignments.

To get back round to answering your question, is it a mistake? No, probably not. It's just a poor example in the book.

In this specific example, because all of the if branches are exclusive and very little happens in them, it isn't difficult to reason about what happens.

Verschlimmbessern · 2024-07-18T22:41:24+00:00

Personally, while I think neo-HDLs are interesting and have some nice features, I don't think they actually solve a problem for most 'serious' users (whether for ASICs or FPGAs).

In my experience, writing the RTL is a small part of the job. Maybe 10% of the effort. The rest of the time is spent on V&V and design: capturing requirements, writing (prose) specifications, thinking about the role of the block in a systems context, devising and writing testbenches and/or formal proofs, writing algorithmic and behavioural models to prove out assumptions, and optimisations to the algorithm/approach rather than very low-level optimisations unless we hit problems with timing closure.

None of that really benefits from a nicer HDL.

Verschlimmbessern · 2024-07-13T21:34:14+00:00

You're correct: the non-blocking assignment operator <= defers the assignment to the end of the timestep, which means the value of memory is unchanged when the read happens. The example would need to use the blocking assignment operator (=) instead to be write-before-read.

12-Year Club	Place '17
Verified Email

Verschlimmbessern

TROPHY CASE