Atom HDL

Hello,

Atom is a new high-level hardware description language embedded in
the functional language Haskell.  Atom compiles circuit descriptions
in conditional term rewriting systems down to Verilog and VHDL
for IC simulation, verification, and synthesis.

Programming in Atom feels a lot like object oriented design because
module interfaces use methods, instead of just wires and bits.

We've used Atom successfully on several different "test" designs
including bus arbitration, packet routing, memory interfaces,
DSP, serial interface controllers, and error correction coding.
In fact, an early version of Atom compiled the 802.11an LDPC
codec posted to opencores.org.

The language is a bit in flux, and the documentation, tutorial,
and examples are pretty sparse.  But if you're interested
in new ways to design hardware, and your not intimidated
by Haskell, give Atom a try.  It's free.

  http://funhdl.org/wiki/doku.php/atom

-Tom

On May 3, 9:47 pm, Tom <tomahawk...@gmail.com> wrote:
> Hello,
>
> Atom is a new high-level hardware description language embedded in
> the functional language Haskell.  Atom compiles circuit descriptions
> in conditional term rewriting systems down to Verilog and VHDL
> for IC simulation, verification, and synthesis.
>
> Programming in Atom feels a lot like object oriented design because
> module interfaces use methods, instead of just wires and bits.
>
> We've used Atom successfully on several different "test" designs
> including bus arbitration, packet routing, memory interfaces,
> DSP, serial interface controllers, and error correction coding.
> In fact, an early version of Atom compiled the 802.11an LDPC
> codec posted to opencores.org.
>
> The language is a bit in flux, and the documentation, tutorial,
> and examples are pretty sparse.  But if you're interested
> in new ways to design hardware, and your not intimidated
> by Haskell, give Atom a try.  It's free.
>
>  http://funhdl.org/wiki/doku.php/atom
>
> -Tom

Looks interesting, but very little info on the website.
How does this compare to Lava (Haskell), HDFS (F#) or i was going to
say confluence, (but it looks like confluence is becoming Atom)?
Has anyone outside of the developers tried any of these or have
opinions?

tkvhdl@gmail.com wrote:
> On May 3, 9:47 pm, Tom <tomahawk...@gmail.com> wrote:
> 
>>Hello,
>>
>>Atom is a new high-level hardware description language embedded in
>>the functional language Haskell.  
<snip>>
>> http://funhdl.org/wiki/doku.php/atom

> Looks interesting, but very little info on the website.
> How does this compare to Lava (Haskell), HDFS (F#) or i was going to
> say confluence, (but it looks like confluence is becoming Atom)?
> Has anyone outside of the developers tried any of these or have
> opinions?
> 

There is also this Python-derived flow :

http://myhdl.jandecaluwe.com/doku.php/start

How does Atom compare with that?
MyHDL is also a 'cross-compiler', that exports verilog code.

-jg

On May 4, 2:31 pm, "tkv...@gmail.com" <tki...@gmail.com> wrote:
>
> Looks interesting, but very little info on the website.
> How does this compare to Lava (Haskell), HDFS (F#) or i was going to
> say confluence, (but it looks like confluence is becoming Atom)?

Lava, HDFS, HDCaml, and Confluence use functional programing to
describe
the structure of a hardware circuit.  In these languages, functions
are used
to assemble parametric hardware blocks from a collection of logic
primitives
(eg. gates, arithmetics, comparisons, registers, etc).  Lava is step
above the
crowd in that it also gives the designer control of layout.

Even though these languages offer many benefits over Verilog and VHDL,
designers still must manually wire up every logic primitive in the
design.
Thus, one could argue they are still at the register transfer
abstraction level (RTL).

Atom is bit different.  Designers still have to declare registers and
combinational
functions of these registers, but now Atom synthesizes control logic
to connect
the combinational functions to the register inputs for the next-state
calculations.
In a sense, the Atom compiler is now making design decisions that a
human has
to do today with any RTL HDL (Verilog, VHDL, Lava, HDFS, et al).

To address Jim's question in the following post:
> There is also this Python-derived flow :
> How does Atom compare with that?
> MyHDL is also a 'cross-compiler', that exports verilog code.

I don't have experience with MyHDL, so my statements may need to be
qualified.  From what
I gather, MyHDL very closely approximates the semantics of Verilog
(@always(clock.posedge)).
Therefore I suspect, in terms of synthesis, MyHDL is still at RTL.

Where MyHDL shines, is it's ability to simulate within it's host
language, Python.
If locked in a room with SystemVerilog and Python, I'd take Python any
day.  If offered
OCaml or Haskell, I'll always reach for higher-order functional
languages.

-Tom

Tom wrote:

> I don't have experience with MyHDL, so my statements may need to be
> qualified.  From what
> I gather, MyHDL very closely approximates the semantics of Verilog
> (@always(clock.posedge)).
> Therefore I suspect, in terms of synthesis, MyHDL is still at RTL.

I think I disagree.
RTL++ anyway.

Have a look at this example.
source:
http://myhdl.jandecaluwe.com/doku.php/cookbook:sinecomp
object:
http://home.comcast.net/~mike_treseler/sinecomputer.pdf

  -- Mike Treseler

On May 4, 10:59 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> Tom wrote:
> > I don't have experience with MyHDL, so my statements may need to be
> > qualified.  From what
> > I gather, MyHDL very closely approximates the semantics of Verilog
> > (@always(clock.posedge)).
> > Therefore I suspect, in terms of synthesis, MyHDL is still at RTL.
>
> I think I disagree.
> RTL++ anyway.
>
> Have a look at this example.
> source:http://myhdl.jandecaluwe.com/doku.php/cookbook:sinecomp

I would even say it's RTL# -- there's a ton of cool elaboration taking
place.  But "yield clock.posedge" is still just an always block.

Here's how a cordic processor could look in Atom.  Atom's strength is
control logic.  So for clarity, I'll ignore the datapath details:

  http://funhdl.org/wiki/doku.php/atom:tutorial:cordic

Unlike RTL, Atom's module interfaces are object-oriented.  If an
external block wants to start a computation, it calls the loadData
method.  When it wants the result, it calls getResult.

In addition, such interfaces support multiple consumers and
producers.  If two blocks are trying to call loadData at the same
time, the Atom compiler will automatically handle the arbitration.

More importantly, the Atom compiler guarantees correctness across
module interfaces.  If CORDIC is known to be correct on the inside,
there is nothing an external block can do to break it from the
outside.

-Tom

On May 4, 12:47 am, Tom <tomahawk...@gmail.com> wrote:
> Atom is a new high-level hardware description language embedded in
> the functional language Haskell.  Atom compiles circuit descriptions
> in conditional term rewriting systems down to Verilog and VHDL
> for IC simulation, verification, and synthesis.

I'll take a look...

Sounds a lot like Bluespec, what can you say about the differences
between the two?

Edmond

Tom wrote:

> I don't have experience with MyHDL, so my statements may need to be
> qualified.  From what
> I gather, MyHDL very closely approximates the semantics of Verilog
> (@always(clock.posedge)).

VHDL semantics actually, where it really matters (i.e. a clear
separation between Signal objects and plain variables.)

> Therefore I suspect, in terms of synthesis, MyHDL is still at RTL.
> 
> Where MyHDL shines, is it's ability to simulate within it's host
> language, Python.
> If locked in a room with SystemVerilog and Python, I'd take Python any
> day.  If offered
> OCaml or Haskell, I'll always reach for higher-order functional
> languages.

I believe that the usage of the term "RTL" creates a lot of confusion,
as I hope to clarify below.

The way I see it, there are two schools of thought in HDLs, depending
on the way they treat events and (hardware) registers:

* Type 1: explicit registers & implicit events
HDLs based on functional languages seem the be all of this type.

* Type 2: explicit events & implicit registers
This is the model of HDLs such as VHDL and Verilog (and MyHDL).
VHDL signals and variables, and Verilog regs, are all objects
that may become registers, or not, in hardware, depending on
how they are used in the code. Thus, registers are implicit.

Regarding the term RTL - Register Transfer Language - it seems clear
that it's appropriate terminology for type 1 languages. But how
could it be meaningful for type 2 languages - languages
without "register objects"?

It might even be argued that type 2 languages concentrate more
on hardware behavior instead of implementation, and therefore
should be considered "higher level".

More interestingly, there seems to be correlation between the
language type and the kind of semantics provided. Clearly,
all HDLs need concurrent statements - such as VHDL processes
and Verilog always blocks. However, type 1 languages seem
to stop there, while type 2 languages provide sequential
statements also (inside processes and always blocks).

So in my view, type 2 semantics is a superset of type 1.
Type 2 is more successful simply because it is more
powerful.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Jan Decaluwe wrote:

> It might even be argued that type 2 languages concentrate more
> on hardware behavior instead of implementation, and therefore
> should be considered "higher level".

I agree. Inside a synchronous block/process of
a Type 2 RTL description, I can be as procedural
as I like. Synthesis will take care of the pesky
details of inferring the LUTs, registers,
and those wires to hook them up.

However, when it comes to wiring up blocks and modules,
my procedural inclinations are thwarted.
I'm ready for Type 3.

  -- Mike Treseler

>
> I believe that the usage of the term "RTL" creates a lot of confusion,
> as I hope to clarify below.
>
> The way I see it, there are two schools of thought in HDLs, depending
> on the way they treat events and (hardware) registers:
>
> * Type 1: explicit registers & implicit events
> HDLs based on functional languages seem the be all of this type.
>
> * Type 2: explicit events & implicit registers
> This is the model of HDLs such as VHDL and Verilog (and MyHDL).
> VHDL signals and variables, and Verilog regs, are all objects
> that may become registers, or not, in hardware, depending on
> how they are used in the code. Thus, registers are implicit.
>
> Regarding the term RTL - Register Transfer Language - it seems clear
> that it's appropriate terminology for type 1 languages. But how
> could it be meaningful for type 2 languages - languages
> without "register objects"?


I think it is.  For hardware that is actually synthesizable, there are
really only two standard event models which are useful:

always @*
always @(posedge clock[, posedge reset])

Thus we still only really have combinatorial or registered logic.  It
strikes me as more confusing than useful that "regs" or "signals" (or
"variables") can be both.

The one grey area is describing latches.  In all my FPGA designs I
have never (intentionally) used them.  In the one ASIC project I
worked on that did allow them, they had to be instantiated as a
library component which is easily supported by most HDLs.


>
> It might even be argued that type 2 languages concentrate more
> on hardware behavior instead of implementation, and therefore
> should be considered "higher level".
>


What in particular do think makes it higher level?  At the end of the
day we still only desribe one of two things - combinatorial logic or
registers.  The only difference is in type 1 is it defined when the
"object" is created and in type 2 it is inferred from it's
environment.  The later seems more clumsy to me.


> More interestingly, there seems to be correlation between the
> language type and the kind of semantics provided. Clearly,
> all HDLs need concurrent statements - such as VHDL processes
> and Verilog always blocks. However, type 1 languages seem
> to stop there, while type 2 languages provide sequential
> statements also (inside processes and always blocks).
>


I agree that the sequential style of coding is useful, however, it is
available in both HDCaml and HDFS.  In fact the model provided there
is, in my opinion, more powerful than VHDL and Verilog (I dont know
about MyHDL) as the constructs can be manipulated programatically by
the host language.

The abstraction provided by atom is a whole different kettle of fish
which significantly changes the way you think about circuit design.
Of all the HDLs mentioned so far it's the only one I consider can
truly be called "higher level".

Please dont for a second consider this any sort of criticism of MyHDL
- it's a very good idea with a great implementation.  For my part,
however, I prefer the functional programming approach - I just wish
more people agreed...

Cheers,

Andy.