13 ms·

Ask HN: Asynchronous FPGAs and flowchart programming

63 points by JaCaLet 4y ago

Hello everyone! I've been working to make an FPGA run asynchronously. I think this will be the fastest way to compute. I interned at You Know Solutions and learned the flowchart programming environment they use. Now they have a new technology patented and I'm trying to help realize the potential. The flowchart programs are asynchronous by design and can create parallel computations. I've been trying to reproduce a flowchart program on a FPGA. Does anyone use flowchart programming anymore? Has anyone used a FPGA to run parallel processes or asynchronously?

tbrownaw 4y ago
Async adds a lot of overhead to propagate readiness information alongside every data path and calculate it through every piece of logic. Unless things have changed drastically in the last decade-and-a-half (well, or the professor in that class was wrong), it's way more efficient to just precompute all that and mess with shifting logic between pipeline stages so everything lines up as closely as possible against a shared click signal.
- qualifiedeephd 4y ago
- keikobadthebad 4y ago
  "Way more efficient" as a conceptual and implementation model. But synchronous logic always leaves some speed on the table, since you have to choose the global clock rate for the longest data path that must complete in one clock; for any given path that may be active on a clock, it's likely to not be the longest. In practice it's possible to architect synchronous critical paths with pipelining to keep the worst single-clock data path reasonable, basically spread the work over multiple clock periods so you can select a faster clock rate and so reduce the wasted time on average to the point nobody cares. OP sounds like he stands zero chance of implementing any nontrivial async design if he's talking about 'flowchart' rtl generation in the same breath.
  - deleted 4y ago
    [deleted]
  - thesz 4y ago
    You forgot that clock delay is computed for worst-case register and combinational logic behavior, e.g., "99.9999% of all registers need this amount of time for signal to be stable before write", "99.9999% of this gate in real silicon will have this delay". The chart I saw several years ago put about half of typical clock cycle delay into this "reserve time" part. I guess things did not change much since then.
    - keikobadthebad 4y ago
      It depends what you are doing but with async it's possible to synthesize SR latches that don't have these setup / hold and metastability problems, the output of the logic is directly strobes that set or reset the storage element.
sshlocalhost98 4y ago
Isn’t the purpose of an FPGA is to run parallel processes? Parallel meaning 2 actions taking place at the same time
- dragontamer 4y ago
  Not necessarily. Its just that CPUs are better at sequential so you'd only really use an FPGA if you had grossly parallel plans. And GPUs are better at some set of parallel operations. So you'd only use an FPGA if you needed to do something GPUs and CPUs couldn't do, especially because of how cheap CPUs / GPUs are.
  - xwa32 4y ago
    FPGAs can be low cost too. Another reason to use them is when you need a ton of IO, or my preferred application, real time control systems. In many cases I find it’s easier to get very precise, and predictable, timing in an FPGA.
    - sshlocalhost98 4y ago
      Thank you sir/ma’am for the explanation!
  - sshlocalhost98 4y ago
    Thank you sir/ma’am for the explanation!
tkanarsky 4y ago
FPGA is literally as parallel as you can make a computation, the ultimate jaunt towards the space end of the time/space tradeoff. Don't like waiting two cycles for your ALU to finish working on previous data? Put another ALU right next to it. So yes, you can totally make a parallel program on an FPGA. As long as there isn't a data or control dependency between two statements, they can be implemented to execute simultaneously. As far as flowchart programming, I'm not sure what advantages that would confer over existing HLS tooling.
- qualifiedeephd 4y ago
- JaCaLet 4y ago
  The flowchart programming is built to be parallel. It’s inherent to the ordering of execution.
xodjmk 4y ago
Parallel yes, as other people mentioned, this is almost the entire point of using FPGAs. Regarding Asynchronous, it depends on what you mean. Xilinx(AMD)/Altera(Intel) FPGAs are designed from bottom up to be synchronously clocked. The fabric and tools are designed to use synchronous pipeline registers everywhere to minimize combinatorial logic and increase throughput. You might want to have a design with multiple asynchronous clock domains, but this increases complexity and requires care whenever you want to jump between clock domains. Trying to force asynchronous design into an FPGA seems counter productive. What would be the advantage of asynchronous design?
- avmich 4y ago
  > What would be the advantage of asynchronous design? Just the regular advantages, only with FPGA, which means one can choose how logical elements are interconnected, and what's the logic of the chip. Among regular advantages are absence of clocks (less devices, no need to synchronize...) and energy is used when and where the switching happens. A friend of mine unsuccessfully tried to squeeze asynchronous designs into some mainstream FPGA a few years ago. Tooling wasn't cooperative, and when he used some workarounds to avoid generating clocks, it was simply crashing. I don't think it's useless or for lack of trying - but asynchronous circuits in FPGAs are certainly not common.
  - moring 4y ago
    > choose how logical elements are interconnected On the RTL level, you can already do that with FPGAs. On the physical level, you can't do that with an asynchronous design either. > absence of clocks (less devices The clocks are still there physically and consume space, even if you don't use them. > no need to synchronize Synchronization becomes very easy when the clocks are aligned and the frequencies are multiples of each other. FPGAs have delay elements in the clock blocks to help with the alignment. > energy is used when and where the switching happens. There are several points of energy use: * the clock network -- you are right about this. Does anyone know how much of the total energy use goes into the clock network? * registers and downstream logic -- behaves the same, whether synchronously or asynchronously. A register that doesn't "flip" will not consume energy for that, and the downstream logic will not flip either. * whatever the asynchronous logic needs for coordination -- don't forget that this is not for free. Analyze energy consumption first before jumping to conclusions or even measures. The whole energy topic reeks of premature optimization.
xwa32 4y ago
Before you go too far down this path you should look into previous works and understand why they failed. There’s a ton of information out there on this. Here’s something to get you started: https://www.eetimes.com/startups-try-to-revive-null-convention-logic/ https://www.eetimes.com/startups-try-to-revive-null-conventi...
- Robin_Message 4y ago
  And ARM had clockless processor prototypes in 2006; I remember learning about them at university. https://www.eetimes.com/arm-clockless-core-cuts-power-to-about-a-third/ https://www.eetimes.com/arm-clockless-core-cuts-power-to-abo...
blu_line 4y ago
First of all google is your friend. Search for Muller-C, asynchronous communication As a starter, have a look at these paper: http://www2.imm.dtu.dk/pubdb/edoc/imm7126.pdf http://www2.imm.dtu.dk/pubdb/edoc/imm7126.pdf https://essay.utwente.nl/79740/1/YADAV_MA_EEMCS.pdf https://essay.utwente.nl/79740/1/YADAV_MA_EEMCS.pdf
cumshitpiss 4y ago
"Fastest way to compute" This isn't necessarily true, especially considering the architecture of an FPGA. You have no control over the routing of the circuit and you're extremely restricted by the tools (which have decades of work towards synchronous circuits). More often than not, a synchronous circuit will end up being faster and more practical (there's a lot of overhead for async as well). Another issue is that a lot of fundamental asynchronous primitives like the muller C-element and latches aren't really feasible to implement on the fpga (easily). The C-element requires a feedback loop on the LUT which is really hard to constrain properly, and the tool will fight you for doing that. There's a cryptography paper out there comparing a synchronous and asynchronous implementation of ciphers and the conclusion was that synchronous was easier to implement and had higher throughput
- xwa32 4y ago
  There's a lot of interesting research out there as designers having been toying with asynchronous for decades. For example this one sponsored by Intel where they put an asynchronous instruction length decoder into a Pentium. https://my.eng.utah.edu/~kstevens/docs/rappid.pdf https://my.eng.utah.edu/~kstevens/docs/rappid.pdf They won on latency and power with comparable area. The issue that blocked it was DFT CAD and the ATE infrastructure doesn't exist for asynchronous designs.
hutzlibu 4y ago
"I interned at You Know Solutions and learned the flowchart programming environment they use. " And what do they use? How does it work, do you click your flowcharts together?
- balsam 4y ago
  Their patent seem to mention flowcharts: https://www.freepatentsonline.com/9003383.html https://www.freepatentsonline.com/9003383.html
  - JaCaLet 4y ago
    Yup the flowcharts are the key to the parallelizing of code
  - atomicflow 4y ago
    I am familiar with the you know solutions patents and the one you refer to is for parallelizing C code and other languages into the flowcharts. Here is a link to the asynchronous design patent called "processing circuits for parallel asynchronous modeling and execution". https://www.freepatentsonline.com/10181003.html https://www.freepatentsonline.com/10181003.html
    - hutzlibu 4y ago
      Interesting, but not great, since I work on something related and I was not aware of any patents in that area. But it should be distinct enough, I hope. (I don't target FPGAs for example, but I have zero experience with patents, so lets see how that works out)
- JaCaLet 4y ago
  It’s similar to ladder logic. It’s called FlowPro. You can combine flowcharts together that’s easy.
  - atomicflow 4y ago
    It's not really similar to ladder logic but in those days it did the same thing, controlled machines. In ladder logic all of the rungs of the ladder are evaluated all of the time but with flowcharts only the necessary part of each flowchart is executed as the machine cycles.
miga 4y ago
Looks like you want to implement "asynchronous circuit": https://en.wikipedia.org/wiki/Asynchronous_circuit https://en.wikipedia.org/wiki/Asynchronous_circuit These basically need a handshaking logic for every independent data path.
- atomicflow 4y ago
  Take a look at the you know solutions patent. It doesn't use handshaking and the design can be clockless. https://www.freepatentsonline.com/10181003.html https://www.freepatentsonline.com/10181003.html
  - xwa32 4y ago
    The main issue with the comments are people are mixing terms without knowing it. To many a single instruction executed on a CPU is an atomic event. This is not the case for a circuit designer (and FPGAs are closer to circuit design as technically what you're doing is configuring them) For us an instruction on a CPU is a sequence of many smaller events, sometimes happening in parallel, which all need to be properly ordered to get a correct result. The most basic example is adding two multi-bit numbers, as was given in tremon's earlier comment, how does the next circuit know that all the bits in the result are ready to be consumed? To us those are parallel processes too, and we synchronize them. Sometimes by design (i.e. this process is guaranteed to complete before the next tick) and sometimes with a separate handshaking circuit. But no matter what, there is always some form of synchronization present in the machine itself.
    - atomicflow 4y ago
      If you step back and look at a flowchart or thousands of flowcharts that represent parallel tasks, I think the object of the patent is to get those flowcharts to propagate (i.e. execute on their own) without a processor. The propagation flow is always forward (not requiring a handshake) until a loopback is reached on the flowchart. A new propagation begins at the loopback destination block. The new propagation flow may or may not follow the same flowchart past depending on decision events. Synchronization takes place at the flowchart level and not at the circuit level. To synchronize, one flowchart sets a variable and other flowcharts can test the variable and decide what to do. The flowcharts are the code which synthesize directly to action, test and task objects without Boolean or state machine structures. These structures (circuits) are synchronous when the flowcharts are implemented in a standard FPGA but the flowcharts themselves remain asynchronous. The patent mentions an FPFA (field programmable flowchart array) that would use clock less circuitry.
ajb 4y ago
Not sure if you are actually talking about clockless logic. Maybe you are talking about asynchrony at a higher level of granularity. But in fact there was a company founded to make FPGAs based on clockless logic: Achronix. They found that their customers wanted to map clocked designes onto their FPGAs and don't make any noise about clockless anymore - possibly their designs still use it under the hood, possibly not.
- JaCaLet 4y ago
  Yes clockless logic no handshaking
  - gaudat 4y ago
    What handshaking? Never heard of that before.
  - xwa32 4y ago
    Even the most trivial design will need some form of synchronization which implies handshaking of some kind. Asynchronous design is a really interesting field where it's pretty easy to get wins at the circuit level, but it's much harder to win at the system level. Especially when you realize there is no rule that says the system needs only one clock domain, and the period of those domains doesn't actually have to be constant. I highly recommend you spend some time with a recent overview in the field if you're serious about it. Here is a good one: http://www.cs.columbia.edu/~nowick/nowick-singh-async-IEEE-DT-15-overview-article-pt1.pdf http://www.cs.columbia.edu/~nowick/nowick-singh-async-IEEE-D...
fjfaase 4y ago
You might want to ask Maya Posch about her experiences. See: https://mayaposch.wordpress.com/category/programming/vhdl/ https://mayaposch.wordpress.com/category/programming/vhdl/
auxym 4y ago
Labview provides a dataflow programming environment that can be used to program FPGAs (eg in the compactRIO line of hardware). Not saying it's great (it's not), but it works in its niche: programming of one-off test fixtures by people who really have no idea about programming, digital circuits or FPGAs but might need the performance they afford (eg real-time high frequency control of a 100K+ RPM prototype gas turbine). You also have to be willing to shell out for their hardware (and labview itself), but in the testing world, I've found their hardware to actually be on the "pretty affordable for what you get" side, compared to the likes of HBM eDAQ or Siemens LMS setups.
nalzok 4y ago
You should check out GreenArrays. Their G144A12 is an amazing little asynchronous chip. It's not an FPGA though.
- JaCaLet 4y ago
  I am aware of these guys and they have been around for years. The only similarity is that they have an asynchronous chip but it is implemented in the old classic asynchronous design approach with specialty circuits for their language. The language they use is Forth a ‘stack based’ language.
freemint 4y ago
I know of people who build a microprocessor in SimuLink.
FunnyBadger 4y ago
You may want to look up asynchronous logic - it's more complicated that you realize. In fact, you'll quickly understand why 99% of all digital designs use synchronous logic design instead - it has a far smaller gate count to accomplish the same function. There are legitimate places where asynchronous logic can be very useful: specifically when you are interacting with the "real world" which is not synchronous. But once you get beyond that, going back to synchronous design is usually best. http://www2.imm.dtu.dk/pubdb/edoc/imm855.pdf http://www2.imm.dtu.dk/pubdb/edoc/imm855.pdf https://www.researchgate.net/publication/245530456_Asynchronous_Circuit_Design_Motivation_Background_Methods https://www.researchgate.net/publication/245530456_Asynchron... https://www.researchgate.net/publication/331181568_Asynchronous_Design_--_Part_2_Systems_and_Methodologies https://www.researchgate.net/publication/331181568_Asynchron...

63 points by JaCaLet 4y ago

tbrownaw 4y ago

Async adds a lot of overhead to propagate readiness information alongside every data path and calculate it through every piece of logic. Unless things have changed drastically in the last decade-and-a-half (well, or the professor in that class was wrong), it's way more efficient to just precompute all that and mess with shifting logic between pipeline stages so everything lines up as closely as possible against a shared click signal.

qualifiedeephd 4y ago
keikobadthebad 4y ago
"Way more efficient" as a conceptual and implementation model. But synchronous logic always leaves some speed on the table, since you have to choose the global clock rate for the longest data path that must complete in one clock; for any given path that may be active on a clock, it's likely to not be the longest. In practice it's possible to architect synchronous critical paths with pipelining to keep the worst single-clock data path reasonable, basically spread the work over multiple clock periods so you can select a faster clock rate and so reduce the wasted time on average to the point nobody cares. OP sounds like he stands zero chance of implementing any nontrivial async design if he's talking about 'flowchart' rtl generation in the same breath.
- deleted 4y ago
  [deleted]
- thesz 4y ago
  You forgot that clock delay is computed for worst-case register and combinational logic behavior, e.g., "99.9999% of all registers need this amount of time for signal to be stable before write", "99.9999% of this gate in real silicon will have this delay". The chart I saw several years ago put about half of typical clock cycle delay into this "reserve time" part. I guess things did not change much since then.
  - keikobadthebad 4y ago
    It depends what you are doing but with async it's possible to synthesize SR latches that don't have these setup / hold and metastability problems, the output of the logic is directly strobes that set or reset the storage element.

sshlocalhost98 4y ago

Isn’t the purpose of an FPGA is to run parallel processes? Parallel meaning 2 actions taking place at the same time

dragontamer 4y ago
Not necessarily. Its just that CPUs are better at sequential so you'd only really use an FPGA if you had grossly parallel plans. And GPUs are better at some set of parallel operations. So you'd only use an FPGA if you needed to do something GPUs and CPUs couldn't do, especially because of how cheap CPUs / GPUs are.
- xwa32 4y ago
  FPGAs can be low cost too. Another reason to use them is when you need a ton of IO, or my preferred application, real time control systems. In many cases I find it’s easier to get very precise, and predictable, timing in an FPGA.
  - sshlocalhost98 4y ago
    Thank you sir/ma’am for the explanation!
- sshlocalhost98 4y ago
  Thank you sir/ma’am for the explanation!

tkanarsky 4y ago

FPGA is literally as parallel as you can make a computation, the ultimate jaunt towards the space end of the time/space tradeoff. Don't like waiting two cycles for your ALU to finish working on previous data? Put another ALU right next to it. So yes, you can totally make a parallel program on an FPGA. As long as there isn't a data or control dependency between two statements, they can be implemented to execute simultaneously. As far as flowchart programming, I'm not sure what advantages that would confer over existing HLS tooling.

qualifiedeephd 4y ago
JaCaLet 4y ago
The flowchart programming is built to be parallel. It’s inherent to the ordering of execution.

xodjmk 4y ago

Parallel yes, as other people mentioned, this is almost the entire point of using FPGAs. Regarding Asynchronous, it depends on what you mean. Xilinx(AMD)/Altera(Intel) FPGAs are designed from bottom up to be synchronously clocked. The fabric and tools are designed to use synchronous pipeline registers everywhere to minimize combinatorial logic and increase throughput. You might want to have a design with multiple asynchronous clock domains, but this increases complexity and requires care whenever you want to jump between clock domains. Trying to force asynchronous design into an FPGA seems counter productive. What would be the advantage of asynchronous design?

avmich 4y ago
> What would be the advantage of asynchronous design? Just the regular advantages, only with FPGA, which means one can choose how logical elements are interconnected, and what's the logic of the chip. Among regular advantages are absence of clocks (less devices, no need to synchronize...) and energy is used when and where the switching happens. A friend of mine unsuccessfully tried to squeeze asynchronous designs into some mainstream FPGA a few years ago. Tooling wasn't cooperative, and when he used some workarounds to avoid generating clocks, it was simply crashing. I don't think it's useless or for lack of trying - but asynchronous circuits in FPGAs are certainly not common.
- moring 4y ago
  > choose how logical elements are interconnected On the RTL level, you can already do that with FPGAs. On the physical level, you can't do that with an asynchronous design either. > absence of clocks (less devices The clocks are still there physically and consume space, even if you don't use them. > no need to synchronize Synchronization becomes very easy when the clocks are aligned and the frequencies are multiples of each other. FPGAs have delay elements in the clock blocks to help with the alignment. > energy is used when and where the switching happens. There are several points of energy use: * the clock network -- you are right about this. Does anyone know how much of the total energy use goes into the clock network? * registers and downstream logic -- behaves the same, whether synchronously or asynchronously. A register that doesn't "flip" will not consume energy for that, and the downstream logic will not flip either. * whatever the asynchronous logic needs for coordination -- don't forget that this is not for free. Analyze energy consumption first before jumping to conclusions or even measures. The whole energy topic reeks of premature optimization.

xwa32 4y ago

Before you go too far down this path you should look into previous works and understand why they failed. There’s a ton of information out there on this. Here’s something to get you started: https://www.eetimes.com/startups-try-to-revive-null-convention-logic/ https://www.eetimes.com/startups-try-to-revive-null-conventi...

Robin_Message 4y ago
And ARM had clockless processor prototypes in 2006; I remember learning about them at university. https://www.eetimes.com/arm-clockless-core-cuts-power-to-about-a-third/ https://www.eetimes.com/arm-clockless-core-cuts-power-to-abo...

blu_line 4y ago

First of all google is your friend. Search for Muller-C, asynchronous communication As a starter, have a look at these paper: http://www2.imm.dtu.dk/pubdb/edoc/imm7126.pdf http://www2.imm.dtu.dk/pubdb/edoc/imm7126.pdf https://essay.utwente.nl/79740/1/YADAV_MA_EEMCS.pdf https://essay.utwente.nl/79740/1/YADAV_MA_EEMCS.pdf

cumshitpiss 4y ago

"Fastest way to compute" This isn't necessarily true, especially considering the architecture of an FPGA. You have no control over the routing of the circuit and you're extremely restricted by the tools (which have decades of work towards synchronous circuits). More often than not, a synchronous circuit will end up being faster and more practical (there's a lot of overhead for async as well). Another issue is that a lot of fundamental asynchronous primitives like the muller C-element and latches aren't really feasible to implement on the fpga (easily). The C-element requires a feedback loop on the LUT which is really hard to constrain properly, and the tool will fight you for doing that. There's a cryptography paper out there comparing a synchronous and asynchronous implementation of ciphers and the conclusion was that synchronous was easier to implement and had higher throughput

xwa32 4y ago
There's a lot of interesting research out there as designers having been toying with asynchronous for decades. For example this one sponsored by Intel where they put an asynchronous instruction length decoder into a Pentium. https://my.eng.utah.edu/~kstevens/docs/rappid.pdf https://my.eng.utah.edu/~kstevens/docs/rappid.pdf They won on latency and power with comparable area. The issue that blocked it was DFT CAD and the ATE infrastructure doesn't exist for asynchronous designs.

hutzlibu 4y ago

"I interned at You Know Solutions and learned the flowchart programming environment they use. " And what do they use? How does it work, do you click your flowcharts together?

balsam 4y ago
Their patent seem to mention flowcharts: https://www.freepatentsonline.com/9003383.html https://www.freepatentsonline.com/9003383.html
- JaCaLet 4y ago
  Yup the flowcharts are the key to the parallelizing of code
- atomicflow 4y ago
  I am familiar with the you know solutions patents and the one you refer to is for parallelizing C code and other languages into the flowcharts. Here is a link to the asynchronous design patent called "processing circuits for parallel asynchronous modeling and execution". https://www.freepatentsonline.com/10181003.html https://www.freepatentsonline.com/10181003.html
  - hutzlibu 4y ago
    Interesting, but not great, since I work on something related and I was not aware of any patents in that area. But it should be distinct enough, I hope. (I don't target FPGAs for example, but I have zero experience with patents, so lets see how that works out)
JaCaLet 4y ago
It’s similar to ladder logic. It’s called FlowPro. You can combine flowcharts together that’s easy.
- atomicflow 4y ago
  It's not really similar to ladder logic but in those days it did the same thing, controlled machines. In ladder logic all of the rungs of the ladder are evaluated all of the time but with flowcharts only the necessary part of each flowchart is executed as the machine cycles.

miga 4y ago

Looks like you want to implement "asynchronous circuit": https://en.wikipedia.org/wiki/Asynchronous_circuit https://en.wikipedia.org/wiki/Asynchronous_circuit These basically need a handshaking logic for every independent data path.

atomicflow 4y ago
Take a look at the you know solutions patent. It doesn't use handshaking and the design can be clockless. https://www.freepatentsonline.com/10181003.html https://www.freepatentsonline.com/10181003.html
- xwa32 4y ago
  The main issue with the comments are people are mixing terms without knowing it. To many a single instruction executed on a CPU is an atomic event. This is not the case for a circuit designer (and FPGAs are closer to circuit design as technically what you're doing is configuring them) For us an instruction on a CPU is a sequence of many smaller events, sometimes happening in parallel, which all need to be properly ordered to get a correct result. The most basic example is adding two multi-bit numbers, as was given in tremon's earlier comment, how does the next circuit know that all the bits in the result are ready to be consumed? To us those are parallel processes too, and we synchronize them. Sometimes by design (i.e. this process is guaranteed to complete before the next tick) and sometimes with a separate handshaking circuit. But no matter what, there is always some form of synchronization present in the machine itself.
  - atomicflow 4y ago
    If you step back and look at a flowchart or thousands of flowcharts that represent parallel tasks, I think the object of the patent is to get those flowcharts to propagate (i.e. execute on their own) without a processor. The propagation flow is always forward (not requiring a handshake) until a loopback is reached on the flowchart. A new propagation begins at the loopback destination block. The new propagation flow may or may not follow the same flowchart past depending on decision events. Synchronization takes place at the flowchart level and not at the circuit level. To synchronize, one flowchart sets a variable and other flowcharts can test the variable and decide what to do. The flowcharts are the code which synthesize directly to action, test and task objects without Boolean or state machine structures. These structures (circuits) are synchronous when the flowcharts are implemented in a standard FPGA but the flowcharts themselves remain asynchronous. The patent mentions an FPFA (field programmable flowchart array) that would use clock less circuitry.

ajb 4y ago

Not sure if you are actually talking about clockless logic. Maybe you are talking about asynchrony at a higher level of granularity. But in fact there was a company founded to make FPGAs based on clockless logic: Achronix. They found that their customers wanted to map clocked designes onto their FPGAs and don't make any noise about clockless anymore - possibly their designs still use it under the hood, possibly not.

JaCaLet 4y ago
Yes clockless logic no handshaking
- gaudat 4y ago
  What handshaking? Never heard of that before.
- xwa32 4y ago
  Even the most trivial design will need some form of synchronization which implies handshaking of some kind. Asynchronous design is a really interesting field where it's pretty easy to get wins at the circuit level, but it's much harder to win at the system level. Especially when you realize there is no rule that says the system needs only one clock domain, and the period of those domains doesn't actually have to be constant. I highly recommend you spend some time with a recent overview in the field if you're serious about it. Here is a good one: http://www.cs.columbia.edu/~nowick/nowick-singh-async-IEEE-DT-15-overview-article-pt1.pdf http://www.cs.columbia.edu/~nowick/nowick-singh-async-IEEE-D...

fjfaase 4y ago

You might want to ask Maya Posch about her experiences. See: https://mayaposch.wordpress.com/category/programming/vhdl/ https://mayaposch.wordpress.com/category/programming/vhdl/

auxym 4y ago

Labview provides a dataflow programming environment that can be used to program FPGAs (eg in the compactRIO line of hardware). Not saying it's great (it's not), but it works in its niche: programming of one-off test fixtures by people who really have no idea about programming, digital circuits or FPGAs but might need the performance they afford (eg real-time high frequency control of a 100K+ RPM prototype gas turbine). You also have to be willing to shell out for their hardware (and labview itself), but in the testing world, I've found their hardware to actually be on the "pretty affordable for what you get" side, compared to the likes of HBM eDAQ or Siemens LMS setups.

nalzok 4y ago

You should check out GreenArrays. Their G144A12 is an amazing little asynchronous chip. It's not an FPGA though.

JaCaLet 4y ago
I am aware of these guys and they have been around for years. The only similarity is that they have an asynchronous chip but it is implemented in the old classic asynchronous design approach with specialty circuits for their language. The language they use is Forth a ‘stack based’ language.

freemint 4y ago

I know of people who build a microprocessor in SimuLink.

FunnyBadger 4y ago

You may want to look up asynchronous logic - it's more complicated that you realize. In fact, you'll quickly understand why 99% of all digital designs use synchronous logic design instead - it has a far smaller gate count to accomplish the same function. There are legitimate places where asynchronous logic can be very useful: specifically when you are interacting with the "real world" which is not synchronous. But once you get beyond that, going back to synchronous design is usually best. http://www2.imm.dtu.dk/pubdb/edoc/imm855.pdf http://www2.imm.dtu.dk/pubdb/edoc/imm855.pdf https://www.researchgate.net/publication/245530456_Asynchronous_Circuit_Design_Motivation_Background_Methods https://www.researchgate.net/publication/245530456_Asynchron... https://www.researchgate.net/publication/331181568_Asynchronous_Design_--_Part_2_Systems_and_Methodologies https://www.researchgate.net/publication/331181568_Asynchron...