Of course there are also some pitfalls like metastability that aren't generally an issue with a processor.
Yep. And when translating async logic to an FPGA, this is where the biggest problem is. FPGAs typically work using LUTs which outputs will change (spike) during a change of an input. Such spikes can set/reset flip flops and latches. Creating asynchronous logic using an FPGA is massively difficult and hard to analyse (validate).
But, when a lot of the discrete TTL logic series is being retired and unobtainable and the order from above is to replicate the old circuit, no deviation.
That doesn't seem a plausible reason. TTL style chips are still available. With an FPGA a change to CMOS and/or 3.3V will still need to be made.
There are a whole slew of 74LSxxx or 4000 series parts which are no longer made. Some multi-stable vibrators, BCD up down counters, some magnitude comparators and digital word files (simple ram with separate din/dout) ports. Yes, the basic gates, buffers, latches, FF, un-down counters, serial shift regs are still being produced. The oddballs have been weeded out over the years and if your design relied on one, you are f'ed.
In the FPGA, these oddballs are still in the Quartus' library.
existing discrete logic can be replicated in an FPGA easily
As nctnico says, this doesn't actually work a lot of the time. FPGAs are supposed to be used as fully synchronous designs. You clock a common clock net (or several). One can draw random logic in an FPGA but it will often fail due to uneven delays. If you buy some 74HC or 4000 logic chip, its internal delays have been tweaked to make it work reliably. In an FPGA this does not happen. It can work (I've done it) but it often breaks when the mfg moves to a faster silicon process.
A random logic to FPGA design will probably be a different circuit, all synchronous, and in the case in this thread, probably be a state machine, running off some clock source. Then you are protected from the silicon getting faster.
From what I've seen, aircraft intercoms use simple logic like 4000 series gates, not counters etc.
existing discrete logic can be replicated in an FPGA easily
As nctnico says, this doesn't actually work a lot of the time. FPGAs are supposed to be used as fully synchronous designs. You clock a common clock net (or several). One can draw random logic in an FPGA but it will often fail due to uneven delays. If you buy some 74HC or 4000 logic chip, its internal delays have been tweaked to make it work reliably. In an FPGA this does not happen. It can work (I've done it) but it often breaks when the mfg moves to a faster silicon process.
A random logic to FPGA design will probably be a different circuit, all synchronous, and in the case in this thread, probably be a state machine, running off some clock source. Then you are protected from the silicon getting faster.
From what I've seen, aircraft intercoms use simple logic like 4000 series gates, not counters etc.
synchronous vs. synchronous is sorta similar to logic/fpga vs. software. It splits things into neat little chunks that can be analyzed separately
You can always add flip-flops clocked by a relatively fast clock (200 MHz for example) to the FPGA outputs. This will cure the glitches.
Although the flops will introduce a delay, the overall propagation delay is likely to be substantially shorter compared to what it would be with discrete logic ICs.
<edit>Even adding two more flip-flops on inputs to combat metastability may not be that bad for the propagation delay ...
You can always add flip-flops clocked by a relatively fast clock (200 MHz for example) to the FPGA outputs. This will cure the glitches.
Although the flops will introduce a delay, the overall propagation delay is likely to be substantially shorter compared to what it would be with discrete logic ICs.
Totally. 200 MHz is 5ns delay due to making it synchronous. There will be more total delay from input pin to output pin of course, but clocking the logic at 200 MHz (assuming Fmax of your design is that high) only accounts for at most 5ns.
A single 74LS NAND gate has 10ns delay, an inverter 8ns.
Then you may as well design it properly (synchronously) since now you have to get a different design certified.
Last thing you want in an aviation product is 200MHz on a PCB
A logic replacement job like this could be clocked at 32768Hz.
You can always add flip-flops clocked by a relatively fast clock (200 MHz for example) to the FPGA outputs. This will cure the glitches.
<edit>Even adding two more flip-flops on inputs to combat metastability may not be that bad for the propagation delay ...
That is not going to help if the internal logic is still asynchronous. You'll still have internal glitches which will cause the design to misbehave.
That is not going to help if the internal logic is still asynchronous. You'll still have internal glitches which will cause the design to misbehave.
The clock registers the signals when they're stable. The exact mechanism is as follows:
An input flip flops make sure that changes occur only on clock edges. Once the input flip flops change, the internal logic will keep changing for a while. This is when the glitches occur. After some time, everything stabilizes - no more changes, no more glitches. At this point, the output flip flops register the signals. Static timing analysis (STA) helps you to determine how much time you need between clocks for that to work.
With discrete logic you will have multiple ICs, all with their own delays which will add up, producing the final delay. If you have several consecutive ICs, the delay will be substantial. The logic within FPGA is much faster simply because it is all within a single chip. Even with added clocking delays, it is likely to produce faster reaction than with discrete ICs.
That might've been the exact reason why they used FPGA in this design - to make things faster.
That is not going to help if the internal logic is still asynchronous. You'll still have internal glitches which will cause the design to misbehave.
The clock registers the signals when they're stable. The exact mechanism is as follows:
An input flip flops make sure that changes occur only on clock edges. Once the input flip flops change, the internal logic will keep changing for a while. This is when the glitches occur. After some time, everything stabilizes - no more changes, no more glitches. At this point, the output flip flops register the signals.
That is only true if the logic doesn't contain flipflops/latches (including feedback loops which can behave that way).
You cascade several flip-flops to avoid metastability from asynchronous signals.
It is an interesting, if off-topic, Q as to how the 74xx FPGA "schematic capture" software implemented stuff like ripple counters. They must have done it right.
I suspect that on the Xilinx FPGAs I worked with, the blocks had matched delays by design so they did not glitch, because you could definitely build ripple counters just fine. Why ripple counters? Because when doing say a low power RTC ASIC design, you want a ripple counter.
For sure if sampling async inputs into any synchronous circuit, you need 2 or more D-types in cascade, to avoid metastable sampling. That is another pitfall of "going sync" as opposed to combinational logic.
So now we are even further from doing a "exact demonstrably lookalike" design in an FPGA
It is an interesting, if off-topic, Q as to how the 74xx FPGA "schematic capture" software implemented stuff like ripple counters. They must have done it right.
I suspect that on the Xilinx FPGAs I worked with, the blocks had matched delays by design so they did not glitch, because you could definitely build ripple counters just fine. Why ripple counters? Because when doing say a low power RTC ASIC design, you want a ripple counter.
I don't think these are actually ripple counters but synchronous counters. A ripple counter may not even work in a LUT based FPGA. I'm quite sure Xilinx (and other FPGA manufacturers) have crafted their 74xx and 4000 series logic macros as synchronous elements while assuming logic people implement using these blocks is synchronous (as complex digital designs should be).
ASIC design is a whole different ball game; not comparable with FPGA.
An input flip flops make sure that changes occur only on clock edges. Once the input flip flops change, the internal logic will keep changing for a while. This is when the glitches occur. After some time, everything stabilizes - no more changes, no more glitches. At this point, the output flip flops register the signals.
That is only true if the logic doesn't contain flipflops/latches (including feedback loops which can behave that way).
Any logic can be synchronized.
An input flip flops make sure that changes occur only on clock edges. Once the input flip flops change, the internal logic will keep changing for a while. This is when the glitches occur. After some time, everything stabilizes - no more changes, no more glitches. At this point, the output flip flops register the signals.
That is only true if the logic doesn't contain flipflops/latches (including feedback loops which can behave that way).
Any logic can be synchronized.
True, but it means you can't take a random 74xx circuit and plonk it as-is into an FPGA and expect it to work. That is my point all along. It will need checking for flipflops & latches, simulation and re-design where necessary. You can't only synchronise the outer edges of the circuit and call it a day. That is not enough.
Also, delays through FPGAs can be surprisingly long. Even on modern day ones you can easely get into the tens of ns from input to output if a signal needs to be routed through the FPGA. Add several levels of logic to that and the delays become even longer. On FPGAs with a large die this is a bigger problem than on the smaller ones. In one of the designs I maintain the FPGA is so big (physically) that when all the logic is concentrated in one part of the die, just the delay inside the FPGA makes it impossible to achieve the input / output timing contraints for a 15ns clock period.
I don't think these are actually ripple counters but synchronous counters
I assure you I built a huge long ripple counter made up of a chain of d-types.
The wire file then went to the ASIC company to make the chip.
But I get your point in that a 4060 ripple counter may have been drawn as a sync counter, in Viewlogic 4.
I had a lot of fun in those days
But in the end I got out of FPGAs, due to shitty expensive dongled tools (I got a Russian guy to do patches) which were not capable of opening designs done with older versions, and basically a fast CPU can do most of those jobs, and you are re-using all your existing skills instead of going down a deep rabbit hole which is great for job security in a employed situation but is crap in your own business.
On FPGAs with a large die this is a bigger problem than on the smaller ones. In one of the designs I maintain the FPGA is so big (physically) that when all the logic is concentrated in one part of the die, just the delay inside the FPGA makes it impossible to achieve the input / output timing contraints for a 15ns clock period.
Doesn't have to be big. I had a Spartan-7 design which is literally the smallest of still supported Xilinx FPGAs. They located all the BRAM memory on one side of the FPGA, and many of my pins were on the other side which created timing problems.
Discrete logic will have considerable delays too if you use multiple ICs.
I don't think these are actually ripple counters but synchronous counters
I assure you I built a huge long ripple counter made up of a chain of d-types.
The wire file then went to the ASIC company to make the chip.
Again, an ASIC is completely different compared to an FPGA. FPGAs typically (I'd say by definition) work using LUTs which are memory elements and output glitches due to the way memory elements work. In an ASIC however, you implement logic using actual gates. So the whole glitching problem doesn't exist in an ASIC.
I don't think these are actually ripple counters but synchronous counters
I assure you I built a huge long ripple counter made up of a chain of d-types.
The wire file then went to the ASIC company to make the chip.
Again, an ASIC is completely different compared to an FPGA. FPGAs typically (I'd say by definition) work using LUTs which are memory elements and output glitches due to the way memory elements work. In an ASIC however, you implement logic using actual gates. So the whole glitching problem doesn't exist in an ASIC.
afair, atleast for Xilinx luts, are guaranteed to not glitch of you only change one input, or multiple inputs where all permutations give the same output
Software vs Hardware. it's that simple.
Software can goof up. memory leaks , glitches in the processor, power fluctuations.
Hardware is much more robust.
By the way for true critical applications in avionics they will not use altera/xilinx but switch to quicklogic or actel antifuse FPGA. Those don't suffer from potential configuration bit-flip due to cosmic radiation. And you can get them in rad-hard or low alpha ceramics so the flipflops are rad-hard. (there is a difference between configuration bit-flip where the FPGA fabric itself gets corrupted due to radiation effect and the "runtime" data like flipflop states getting corrupted. The first case could be an AND changing to an OR, the second would be a flipflop going from high to low.)
So you still need low alpha ceramics and RAD shielding. The ceramic packages can contain trace radioactive elements. For rad-hard the packages are a specific ceramic (typically purple-ish in color). They used gold cavities and gold plated lids. This is much thicker than normal plating so it can stop alpha and beta radiation.
The FAA's FTS (Flight Termination System) use FPGA. Not a microcontroller in sight. Certified for launch. They give you the entire design , pcb layout and all. you can't deviate from the design. All you are allowed to do is make the board larger (empty space) and add mounting holes so it fits in your enclosure.
It has to work... If they turn off the pilot tones that rocket must blow up.
Software can goof up. memory leaks , glitches in the processor, power fluctuations.
Software that is a translation of a hardware design does not have memory leaks.
Software can goof up. memory leaks , glitches in the processor, power fluctuations.
Software that is a translation of a hardware design does not have memory leaks.
it's not just memory leaks. race conditions, interrupt timings, handling many events simultaneously. Processors need many cycles to do something that can be done in 1 clock cycle in hard logic. That's the reason those Zync devices are so popular these days. Offload all the "timing hard" stuff to the fpga fabric.
Software can be very undeterministic whe it comes to timing. Hard realtime is very difficult to do and prove it is determinisitc. Logic ? much easier.
Software *can* be undeterministic, but software that emulates a clocked hardware circuit, as in an FPGA, has no reason to be. You have global variables, many of which can be in registers on something like RV32I with 1024 bits of registers, and the rest in equally deterministic SRAM. There is no reason to use interrupts, or if/then/else, or any loops other than the one master loop that corresponds to the FPGA's clock. On a simple in-order CPU the instructions will execute at one per clock cycle.
It will be "hard real time".
It will quite likely be slower than an FPGA. But you easily prove how much slower, and it will always be the same speed, and it might well be fast enough. As Peter-H said, in that avionics application an update rate of 30kHz is probably more than fast enough. That's 1500 instructions on a 10c 48 MHz CH32V003. That's a heck of a lot of TTL emulated. And you could get a 72MHz, 144MHz, 300MHz, 600MHz, 1GHz microcontroller instead if you want.
In this application, scanning the buttons and doing everything needs to be done every 100ms or so. You could clock a CPU at 100Hz
The FAA's FTS (Flight Termination System) use FPGA
I think you mean NASA?
Software can goof up. memory leaks , glitches in the processor, power fluctuations.
Software that is a translation of a hardware design does not have memory leaks.
it's not just memory leaks. race conditions, interrupt timings, handling many events simultaneously. Processors need many cycles to do something that can be done in 1 clock cycle in hard logic. That's the reason those Zync devices are so popular these days. Offload all the "timing hard" stuff to the fpga fabric.
Software can be very undeterministic whe it comes to timing. Hard realtime is very difficult to do and prove it is determinisitc. Logic ? much easier.
Another thing is that pure logic doesn't need a clock so it doesn't need an oscillator. Crystals have a relatively high failure rate and are sensitive to vibration.