MCU with FPGA vs. SoC FPGA

[tggzzz]

They are not intractable. They are just difficult. There are, for example, fully asynchronous DSPs. I'm not clear whether they show any cost performance benefits over more conventional designs. What bothers many people about them is you just don't know how much latency there will be between input and output, as it varies from sample to sample of the device. As long as you design your system for the specified worst case of the device it shouldn't be an issue.

"Asynchronous" means different things to different people.  I learned asynchronous state machine design, which used no FFs.  In essence, the feedback paths, created latches in the logic, but still, there was no clock or enable. 

I've also studied asynchronous processors, which have no free running master clock.  They do have FFs with clock inputs, but the clocks are generated locally, and are stopped when there is no data to process.  The clock is often generated with variable delay, corresponding to the timing of the particular circuit processing the data.  The Green Arrays GA144 has 144 such processors running at 700 MIPS peak in each processor!

The speed advantage of the async processor is in being able to take advantage of portions of the design that are faster than the remainder of the logic.  In a properly clocked design, the entire circuit runs at the speed of the slowest circuit. 

It also achieves speed gains from PVT (Process, Voltage and Temperature).  However, these gains can not be counted on, other than perhaps running at higher or lower voltage to tradeoff speed and power.

and it is much harder to analyse because it is no longer a matter of just checking path from one FF to another is shorter than the clock period

and last time I looked, the precondition to analysis was that only one input changes at a time. Metastability? What's that?

In addition while event transition from one state to another may be well defined, the path it takes to get from one state to the next is not defined or definable. That can lead through illegal intermediate states, which can cause output glitches or even FSM lockup. Hence the need for bridging terms in asynchronous logic specified in Karnaugh maps.

Try getting someone used to HDL simulators and synchronous logic to recognise that! It is an uphill struggle, especially since they don't want to think of such possibilities.

[coppice]

Do you have a reference to the DSP you mention? I'm curious to find out more.

Octasic claim to use asynchronous processing in some of their DSPs. I know another in more detail that I can't talk about.

[nctnico]

Programming those is, in practice, difficult and error prone, largely - I believe - because softies can't think of things occurring in parallel in systems which cannot have a unique concept of time. (For those that doubt that, I refer you to Leslie Lamport's seminal and well-known works!)

'Can't think' is a bit too strong. IMHO the main problem is that parallel execution is not getting much attention during educational programs and hence people trip over something they are not familiar with. When the first multi-threading Intel processors came to market, there was quite a bit of software that couldn't deal with being executed on two CPUs in parallel. The software worked because of luck on a single core machine but fell apart on a multi core machine.

In addition while event transition from one state to another may be well defined, the path it takes to get from one state to the next is not defined or definable. That can lead through illegal intermediate states, which can cause output glitches or even FSM lockup. Hence the need for bridging terms in asynchronous logic specified in Karnaugh maps.

Try getting someone used to HDL simulators and synchronous logic to recognise that! It is an uphill struggle, especially since they don't want to think of such possibilities.

I'm not quite sure typical FPGA fabric (consisting of muxes and LUTs) and HDL tools are suitable to create complex pieces of asynchronous logic in the first place. Sure you can hand craft some amount of logic but for a large design, you'd need tools specially geared to avoid glitches from becoming a problem. This means that the tools need to be able to determine / specify the order in which the signals are connected to a LUT in order to manage output glitches. OR the hardware should somehow filter the glitches but that would mean slowing the logic down. The tools from Xilinx I worked with so far do optimisations at several levels that may screw things up badly at each level.

[gnuarm]

I'm not quite sure typical FPGA fabric (consisting of muxes and LUTs) and HDL tools are suitable to create complex pieces of asynchronous logic in the first place. Sure you can hand craft some amount of logic but for a large design, you'd need tools specially geared to avoid glitches from becoming a problem. This means that the tools need to be able to determine / specify the order in which the signals are connected to a LUT in order to manage output glitches. OR the hardware should somehow filter the glitches but that would mean slowing the logic down. The tools from Xilinx I worked with so far do optimisations at several levels that may screw things up badly at each level.

Some years back, a Xilinx representative said the Xilinx LUT (which is not exactly logic, but transmission gates) is designed to not glitch from inputs changing "at the same time" for some definition of "same time".  I don't recall the basis for this statement, but it included the impact of the output capacitance (of the LUT, not the logic block) preserving state during the transitions.  Hmmm...  it's possible he was talking about a single input changing...

I have no idea what it would take to prevent glitches when using more than one LUT.

[nctnico]

A quick Google search seems to indicate Xilinx has a patent on a LUT structure that does not glitch when 1 input changes. However, with multiple inputs changing, there will be different delays and thus several glitches before a LUT reaches a stable state. Which is what you'd expect from a memory (which a LUT it) because the address decoder has different delays per select line.

[tggzzz]

Programming those is, in practice, difficult and error prone, largely - I believe - because softies can't think of things occurring in parallel in systems which cannot have a unique concept of time. (For those that doubt that, I refer you to Leslie Lamport's seminal and well-known works!)

'Can't think' is a bit too strong. IMHO the main problem is that parallel execution is not getting much attention during educational programs and hence people trip over something they are not familiar with. When the first multi-threading Intel processors came to market, there was quite a bit of software that couldn't deal with being executed on two CPUs in parallel. The software worked because of luck on a single core machine but fell apart on a multi core machine.
 

Agreed in all respects

In addition while event transition from one state to another may be well defined, the path it takes to get from one state to the next is not defined or definable. That can lead through illegal intermediate states, which can cause output glitches or even FSM lockup. Hence the need for bridging terms in asynchronous logic specified in Karnaugh maps.

Try getting someone used to HDL simulators and synchronous logic to recognise that! It is an uphill struggle, especially since they don't want to think of such possibilities.

I'm not quite sure typical FPGA fabric (consisting of muxes and LUTs) and HDL tools are suitable to create complex pieces of asynchronous logic in the first place. Sure you can hand craft some amount of logic but for a large design, you'd need tools specially geared to avoid glitches from becoming a problem. This means that the tools need to be able to determine / specify the order in which the signals are connected to a LUT in order to manage output glitches. OR the hardware should somehow filter the glitches but that would mean slowing the logic down. The tools from Xilinx I worked with so far do optimisations at several levels that may screw things up badly at each level.

Complex, no, and it would be perverse to try. There are potentially some strange niche cases that might benefit, but that doesn't change the point.

It might be possible to implement some asynchronous logic by devious use of the toolset. I don't know how the timing parameters and convergence would interact with the logic.

Of course there are some PL blocks that internally have asynchronous behaviour (e.g. Clock domain crossing blocks), but within a clock domain the tools and implementation are synchronous.

[tggzzz]

I'm not quite sure typical FPGA fabric (consisting of muxes and LUTs) and HDL tools are suitable to create complex pieces of asynchronous logic in the first place. Sure you can hand craft some amount of logic but for a large design, you'd need tools specially geared to avoid glitches from becoming a problem. This means that the tools need to be able to determine / specify the order in which the signals are connected to a LUT in order to manage output glitches. OR the hardware should somehow filter the glitches but that would mean slowing the logic down. The tools from Xilinx I worked with so far do optimisations at several levels that may screw things up badly at each level.

Some years back, a Xilinx representative said the Xilinx LUT (which is not exactly logic, but transmission gates) is designed to not glitch from inputs changing "at the same time" for some definition of "same time".  I don't recall the basis for this statement, but it included the impact of the output capacitance (of the LUT, not the logic block) preserving state during the transitions.  Hmmm...  it's possible he was talking about a single input changing...

I have no idea what it would take to prevent glitches when using more than one LUT.

In synchronous logic there is no problem with multiple combinatorial inputs changing simultaneously, since there are no internal loops (latches/metastability) and provided the outputs become stable before the next clock.

Xilinx's statement may be crect for asynchronous circuits (with internal loops) with "changes at the same time", but if so there must be some combination of changes and times which will cause problems. Unless, I suppose, they have found a way of circumventing metastability in flip flops.

But we (well most of us) realise why FPGAs are for practical intents and purposes, synchronous devices.

[gnuarm]

A quick Google search seems to indicate Xilinx has a patent on a LUT structure that does not glitch when 1 input changes. However, with multiple inputs changing, there will be different delays and thus several glitches before a LUT reaches a stable state. Which is what you'd expect from a memory (which a LUT it) because the address decoder has different delays per select line.

What was the date on that patent?   Patents are only good for 21 years or so. 

[gnuarm]

I'm not quite sure typical FPGA fabric (consisting of muxes and LUTs) and HDL tools are suitable to create complex pieces of asynchronous logic in the first place. Sure you can hand craft some amount of logic but for a large design, you'd need tools specially geared to avoid glitches from becoming a problem. This means that the tools need to be able to determine / specify the order in which the signals are connected to a LUT in order to manage output glitches. OR the hardware should somehow filter the glitches but that would mean slowing the logic down. The tools from Xilinx I worked with so far do optimisations at several levels that may screw things up badly at each level.

Some years back, a Xilinx representative said the Xilinx LUT (which is not exactly logic, but transmission gates) is designed to not glitch from inputs changing "at the same time" for some definition of "same time".  I don't recall the basis for this statement, but it included the impact of the output capacitance (of the LUT, not the logic block) preserving state during the transitions.  Hmmm...  it's possible he was talking about a single input changing...

I have no idea what it would take to prevent glitches when using more than one LUT.

In synchronous logic there is no problem with multiple combinatorial inputs changing simultaneously, since there are no internal loops (latches/metastability) and provided the outputs become stable before the next clock.

Xilinx's statement may be crect for asynchronous circuits (with internal loops) with "changes at the same time", but if so there must be some combination of changes and times which will cause problems. Unless, I suppose, they have found a way of circumventing metastability in flip flops.

But we (well most of us) realise why FPGAs are for practical intents and purposes, synchronous devices.

Not sure where you are going with this.  I was discussing asynch logic state machines which have no FFs.   Why are you talking about this in combination with metastability, which is an issue with clocked FFs?  Did I miss something about metastability?

[tggzzz]

I'm not quite sure typical FPGA fabric (consisting of muxes and LUTs) and HDL tools are suitable to create complex pieces of asynchronous logic in the first place. Sure you can hand craft some amount of logic but for a large design, you'd need tools specially geared to avoid glitches from becoming a problem. This means that the tools need to be able to determine / specify the order in which the signals are connected to a LUT in order to manage output glitches. OR the hardware should somehow filter the glitches but that would mean slowing the logic down. The tools from Xilinx I worked with so far do optimisations at several levels that may screw things up badly at each level.

Some years back, a Xilinx representative said the Xilinx LUT (which is not exactly logic, but transmission gates) is designed to not glitch from inputs changing "at the same time" for some definition of "same time".  I don't recall the basis for this statement, but it included the impact of the output capacitance (of the LUT, not the logic block) preserving state during the transitions.  Hmmm...  it's possible he was talking about a single input changing...

I have no idea what it would take to prevent glitches when using more than one LUT.

In synchronous logic there is no problem with multiple combinatorial inputs changing simultaneously, since there are no internal loops (latches/metastability) and provided the outputs become stable before the next clock.

Xilinx's statement may be crect for asynchronous circuits (with internal loops) with "changes at the same time", but if so there must be some combination of changes and times which will cause problems. Unless, I suppose, they have found a way of circumventing metastability in flip flops.

But we (well most of us) realise why FPGAs are for practical intents and purposes, synchronous devices.

Not sure where you are going with this.  I was discussing asynch logic state machines which have no FFs.   Why are you talking about this in combination with metastability, which is an issue with clocked FFs?  Did I miss something about metastability?

Nctnico's statement (which you quoted, unlike some here ), is about asynchronous logic in FPGAs.
Your response didn't indicate you were only considering synchronous logic.
Hence my comments. That's all.

[gnuarm]

I'm not quite sure typical FPGA fabric (consisting of muxes and LUTs) and HDL tools are suitable to create complex pieces of asynchronous logic in the first place. Sure you can hand craft some amount of logic but for a large design, you'd need tools specially geared to avoid glitches from becoming a problem. This means that the tools need to be able to determine / specify the order in which the signals are connected to a LUT in order to manage output glitches. OR the hardware should somehow filter the glitches but that would mean slowing the logic down. The tools from Xilinx I worked with so far do optimisations at several levels that may screw things up badly at each level.

Some years back, a Xilinx representative said the Xilinx LUT (which is not exactly logic, but transmission gates) is designed to not glitch from inputs changing "at the same time" for some definition of "same time".  I don't recall the basis for this statement, but it included the impact of the output capacitance (of the LUT, not the logic block) preserving state during the transitions.  Hmmm...  it's possible he was talking about a single input changing...

I have no idea what it would take to prevent glitches when using more than one LUT.

In synchronous logic there is no problem with multiple combinatorial inputs changing simultaneously, since there are no internal loops (latches/metastability) and provided the outputs become stable before the next clock.

Xilinx's statement may be crect for asynchronous circuits (with internal loops) with "changes at the same time", but if so there must be some combination of changes and times which will cause problems. Unless, I suppose, they have found a way of circumventing metastability in flip flops.

But we (well most of us) realise why FPGAs are for practical intents and purposes, synchronous devices.

Not sure where you are going with this.  I was discussing asynch logic state machines which have no FFs.   Why are you talking about this in combination with metastability, which is an issue with clocked FFs?  Did I miss something about metastability?

Nctnico's statement (which you quoted, unlike some here ), is about asynchronous logic in FPGAs.
Your response didn't indicate you were only considering synchronous logic.
Hence my comments. That's all.

Sorry, you have stated the situation exactly backwards.  I'm talking about purely asynchronous logic, not synchronous.

How exactly do you see metastability being involved in asynchronous logic?  I'm totally lost.

[tggzzz]

I'm not quite sure typical FPGA fabric (consisting of muxes and LUTs) and HDL tools are suitable to create complex pieces of asynchronous logic in the first place. Sure you can hand craft some amount of logic but for a large design, you'd need tools specially geared to avoid glitches from becoming a problem. This means that the tools need to be able to determine / specify the order in which the signals are connected to a LUT in order to manage output glitches. OR the hardware should somehow filter the glitches but that would mean slowing the logic down. The tools from Xilinx I worked with so far do optimisations at several levels that may screw things up badly at each level.

Some years back, a Xilinx representative said the Xilinx LUT (which is not exactly logic, but transmission gates) is designed to not glitch from inputs changing "at the same time" for some definition of "same time".  I don't recall the basis for this statement, but it included the impact of the output capacitance (of the LUT, not the logic block) preserving state during the transitions.  Hmmm...  it's possible he was talking about a single input changing...

I have no idea what it would take to prevent glitches when using more than one LUT.

In synchronous logic there is no problem with multiple combinatorial inputs changing simultaneously, since there are no internal loops (latches/metastability) and provided the outputs become stable before the next clock.

Xilinx's statement may be crect for asynchronous circuits (with internal loops) with "changes at the same time", but if so there must be some combination of changes and times which will cause problems. Unless, I suppose, they have found a way of circumventing metastability in flip flops.

But we (well most of us) realise why FPGAs are for practical intents and purposes, synchronous devices.

Not sure where you are going with this.  I was discussing asynch logic state machines which have no FFs.   Why are you talking about this in combination with metastability, which is an issue with clocked FFs?  Did I miss something about metastability?

Nctnico's statement (which you quoted, unlike some here ), is about asynchronous logic in FPGAs.
Your response didn't indicate you were only considering synchronous logic.
Hence my comments. That's all.

Sorry, you have stated the situation exactly backwards.  I'm talking about purely asynchronous logic, not synchronous.

How exactly do you see metastability being involved in asynchronous logic?  I'm totally lost.

Is there a confusion between "asynchronous" and "combinatorial"?

If you have a loop in asynchronous logic, then metastability becomes an issue. The simplest example is an RS latch formed by cross-coupled nand gates.

If you are only considering the traditional design pattern where combinatorial logic without loops has its inputs and outputs connected to registers, then metastability in that combinatorial logic cannot occur.

[nctnico]

In theory you can have latches in asynchronous logic but you'll need to setup delay paths to meet setup & hold to avoid metastability. I guess you'd have to analyse the whole circuit as being combinatorial logic. There are probably good books on how to tackle such a project.

[tggzzz]

In theory you can have latches in asynchronous logic but you'll need to setup delay paths to meet setup & hold to avoid metastability. I guess you'd have to analyse the whole circuit as being combinatorial logic. There are probably good books on how to tackle such a project.

If you can find a way to avoid metastability without putting limitations on the external inputs, do yourself (and everybody else) a favour and write it up for publication in, say, an IEEE Journal of record

[nctnico]

In theory you can have latches in asynchronous logic but you'll need to setup delay paths to meet setup & hold to avoid metastability. I guess you'd have to analyse the whole circuit as being combinatorial logic. There are probably good books on how to tackle such a project.

If you can find a way to avoid metastability without putting limitations on the external inputs, do yourself (and everybody else) a favour and write it up for publication in, say, an IEEE Journal of record

There are always limitations where it comes to timing. But the nice thing about asynchronous logic is that it can react to external signals without needing those signals being synchronised to a clock first. Think of a simple D-latch as an example. Or the good old ripple counters like the 7493 (and all its later CMOS incarnations)

[DiTBho]

if you want to see a documented CPU architecture example of what is "microcode", "macrocode", and what runs on the top of what, so to see the boundary between hardware and software, as far as a CPU is concerned, look at the "MIC-1", a processor architecture invented by Andrew Tanenbaum to use as a simple but complete example in his teaching book "Structured Computer Organization", the design is 100% accademic and consists of a very simple control unit that runs microcode from a 512-words store.

oh, now we have the 5th edition of the Holy Book

[DiTBho]

There are always limitations where it comes to timing. But the nice thing about asynchronous logic is that it can react to external signals without needing those signals being synchronised to a clock first.

The perfect example is
- designing a memory mapped device with a FPGA for an asynchronous CPU BUS.
- trying to address an asynchronous static ram with a FPGA.

in both cases
- signals being synchronised to a clock
- latch
- proper sample and hold time as low level high priority project constraints

[tggzzz]

if you want to see a documented CPU architecture example of what is "microcode", "macrocode", and what runs on the top of what, so to see the boundary between hardware and software, as far as a CPU is concerned, look at the "MIC-1", a processor architecture invented by Andrew Tanenbaum to use as a simple but complete example in his teaching book "Structured Computer Organization", the design is 100% accademic and consists of a very simple control unit that runs microcode from a 512-words store.

oh, now we have the 5th edition of the Holy Book

When, in the late 70s, I was wondering how processors were implemented, I triumphantly reinvented microcoding. Didn't realise it at the time, of course.

Then at the turn of the decade I came across the AMD2900 series plus the "Mick and Brick" book.

In the mid 80s I was told to investigate the Research Machines RM1 based on the 2900. Didn't use it.

[tggzzz]

In theory you can have latches in asynchronous logic but you'll need to setup delay paths to meet setup & hold to avoid metastability. I guess you'd have to analyse the whole circuit as being combinatorial logic. There are probably good books on how to tackle such a project.

If you can find a way to avoid metastability without putting limitations on the external inputs, do yourself (and everybody else) a favour and write it up for publication in, say, an IEEE Journal of record

There are always limitations where it comes to timing. But the nice thing about asynchronous logic is that it can react to external signals without needing those signals being synchronised to a clock first. Think of a simple D-latch as an example. Or the good old ripple counters like the 7493 (and all its later CMOS incarnations)

Yes, those are advantages.

But all technologies have their disadvantages; with asynchronous logic there is metastability and dynamic hazards.

[coppice]

if you want to see a documented CPU architecture example of what is "microcode", "macrocode", and what runs on the top of what, so to see the boundary between hardware and software, as far as a CPU is concerned, look at the "MIC-1", a processor architecture invented by Andrew Tanenbaum to use as a simple but complete example in his teaching book "Structured Computer Organization", the design is 100% accademic and consists of a very simple control unit that runs microcode from a 512-words store.

oh, now we have the 5th edition of the Holy Book

When, in the late 70s, I was wondering how processors were implemented, I triumphantly reinvented microcoding. Didn't realise it at the time, of course.

Then at the turn of the decade I came across the AMD2900 series plus the "Mick and Brick" book.

I developed with both the AM2900 and Intel 3000 chipsets for building microcoded machines. In all cases sliding between pure mcirocode, and microcode plus macrocode. Mostly for DSP and graphics applications. You worked with the right chipset. It was way ahead of the Intel one.

That Mick and Brick book was foundational it getting a lot of places started in DSP development.

[tggzzz]

if you want to see a documented CPU architecture example of what is "microcode", "macrocode", and what runs on the top of what, so to see the boundary between hardware and software, as far as a CPU is concerned, look at the "MIC-1", a processor architecture invented by Andrew Tanenbaum to use as a simple but complete example in his teaching book "Structured Computer Organization", the design is 100% accademic and consists of a very simple control unit that runs microcode from a 512-words store.

oh, now we have the 5th edition of the Holy Book

When, in the late 70s, I was wondering how processors were implemented, I triumphantly reinvented microcoding. Didn't realise it at the time, of course.

Then at the turn of the decade I came across the AMD2900 series plus the "Mick and Brick" book.

I developed with both the AM2900 and Intel 3000 chipsets for building microcoded machines. In all cases sliding between pure mcirocode, and microcode plus macrocode. Mostly for DSP and graphics applications. You worked with the right chipset. It was way ahead of the Intel one.

That Mick and Brick book was foundational it getting a lot of places started in DSP development.

I think I still have a databook with the Intel 3000 series. Not many people believe Intel made 2 bit CPUs

[coppice]

if you want to see a documented CPU architecture example of what is "microcode", "macrocode", and what runs on the top of what, so to see the boundary between hardware and software, as far as a CPU is concerned, look at the "MIC-1", a processor architecture invented by Andrew Tanenbaum to use as a simple but complete example in his teaching book "Structured Computer Organization", the design is 100% accademic and consists of a very simple control unit that runs microcode from a 512-words store.

oh, now we have the 5th edition of the Holy Book

When, in the late 70s, I was wondering how processors were implemented, I triumphantly reinvented microcoding. Didn't realise it at the time, of course.

Then at the turn of the decade I came across the AMD2900 series plus the "Mick and Brick" book.

I developed with both the AM2900 and Intel 3000 chipsets for building microcoded machines. In all cases sliding between pure mcirocode, and microcode plus macrocode. Mostly for DSP and graphics applications. You worked with the right chipset. It was way ahead of the Intel one.

That Mick and Brick book was foundational it getting a lot of places started in DSP development.

I think I still have a databook with the Intel 3000 series. Not many people believe Intel made 2 bit CPUs

I had to develop my own line and arc drawing algorithms for an Intel 3000 vector graphics engine we developed. No rasters for us. All, pure point to point scanning across a CRT. Later I found Bresenham had developed the same algorithms, although I included tweaks to improve the smoothness that he didn't seem to document. This was how things were before the Internet let us look things up easily.

[gnuarm]

I'm not quite sure typical FPGA fabric (consisting of muxes and LUTs) and HDL tools are suitable to create complex pieces of asynchronous logic in the first place. Sure you can hand craft some amount of logic but for a large design, you'd need tools specially geared to avoid glitches from becoming a problem. This means that the tools need to be able to determine / specify the order in which the signals are connected to a LUT in order to manage output glitches. OR the hardware should somehow filter the glitches but that would mean slowing the logic down. The tools from Xilinx I worked with so far do optimisations at several levels that may screw things up badly at each level.

Some years back, a Xilinx representative said the Xilinx LUT (which is not exactly logic, but transmission gates) is designed to not glitch from inputs changing "at the same time" for some definition of "same time".  I don't recall the basis for this statement, but it included the impact of the output capacitance (of the LUT, not the logic block) preserving state during the transitions.  Hmmm...  it's possible he was talking about a single input changing...

I have no idea what it would take to prevent glitches when using more than one LUT.

In synchronous logic there is no problem with multiple combinatorial inputs changing simultaneously, since there are no internal loops (latches/metastability) and provided the outputs become stable before the next clock.

Xilinx's statement may be crect for asynchronous circuits (with internal loops) with "changes at the same time", but if so there must be some combination of changes and times which will cause problems. Unless, I suppose, they have found a way of circumventing metastability in flip flops.

But we (well most of us) realise why FPGAs are for practical intents and purposes, synchronous devices.

Not sure where you are going with this.  I was discussing asynch logic state machines which have no FFs.   Why are you talking about this in combination with metastability, which is an issue with clocked FFs?  Did I miss something about metastability?

Nctnico's statement (which you quoted, unlike some here ), is about asynchronous logic in FPGAs.
Your response didn't indicate you were only considering synchronous logic.
Hence my comments. That's all.

Sorry, you have stated the situation exactly backwards.  I'm talking about purely asynchronous logic, not synchronous.

How exactly do you see metastability being involved in asynchronous logic?  I'm totally lost.

Is there a confusion between "asynchronous" and "combinatorial"?

If you have a loop in asynchronous logic, then metastability becomes an issue. The simplest example is an RS latch formed by cross-coupled nand gates.

If you are only considering the traditional design pattern where combinatorial logic without loops has its inputs and outputs connected to registers, then metastability in that combinatorial logic cannot occur.

I've never heard anyone refer to metastability other than in clocked FFs.  Combine that with your comment, "I suppose, they have found a way of circumventing metastability in flip flops" and I have no idea what you are talking about. 

Whatever.  This is not really important.  FPGAs are not intended to be used for asynch logic and no tools for this are provided, to the best of my knowledge.  Such a design would be very difficult to design and verify in an FPGA. 

[gnuarm]

if you want to see a documented CPU architecture example of what is "microcode", "macrocode", and what runs on the top of what, so to see the boundary between hardware and software, as far as a CPU is concerned, look at the "MIC-1", a processor architecture invented by Andrew Tanenbaum to use as a simple but complete example in his teaching book "Structured Computer Organization", the design is 100% accademic and consists of a very simple control unit that runs microcode from a 512-words store.

oh, now we have the 5th edition of the Holy Book

When, in the late 70s, I was wondering how processors were implemented, I triumphantly reinvented microcoding. Didn't realise it at the time, of course.

Then at the turn of the decade I came across the AMD2900 series plus the "Mick and Brick" book.

I developed with both the AM2900 and Intel 3000 chipsets for building microcoded machines. In all cases sliding between pure mcirocode, and microcode plus macrocode. Mostly for DSP and graphics applications. You worked with the right chipset. It was way ahead of the Intel one.

That Mick and Brick book was foundational it getting a lot of places started in DSP development.

I remember using a CAD system based on a 68000 type processor (don't recall exactly which one).  It ran simulations slow as crap.  They had an upgraded system that emulated the 680xx in a bit slice design for a lot more bucks.  A year later they had a system using the next gen of 680xx which was faster than the bit slice and a lot cheaper! 

Bit slice was always, in essence, a research tool.  While you could build systems with it, IC technology was advancing so fast, the bit slice would always be overrun quickly.  I guess there were a few designs that never made it to high volume production, where the bit slice was the right choice. 

[nctnico]

In theory you can have latches in asynchronous logic but you'll need to setup delay paths to meet setup & hold to avoid metastability. I guess you'd have to analyse the whole circuit as being combinatorial logic. There are probably good books on how to tackle such a project.

If you can find a way to avoid metastability without putting limitations on the external inputs, do yourself (and everybody else) a favour and write it up for publication in, say, an IEEE Journal of record

There are always limitations where it comes to timing. But the nice thing about asynchronous logic is that it can react to external signals without needing those signals being synchronised to a clock first. Think of a simple D-latch as an example. Or the good old ripple counters like the 7493 (and all its later CMOS incarnations)

Yes, those are advantages.

But all technologies have their disadvantages; with asynchronous logic there is metastability and dynamic hazards.

No. Metastability only occurs when your timing analysis is incorrect and thus setup & hold times of flipflops are violated. This is equally true for synchronous and asynchronous logic. Metastability is such a fundamental problem for digital designs (*) that working around it, is about the first thing they teach you and thus create robust designs.

* Actually not only for digital designs but for any system be it software or hardware.