Atom HDL

evilkidder@googlemail.com wrote:

> 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.

I have two points to add to the confusion:

* the form "always @(posedge clock[, posedge reset])" is not just for
registered logic, but for combinatorial logic as well. With a few exceptions,
it's probably the only template that you really need.

* it's not just that one variable can be combinatorial and another registered;
to make things worse :-) the *same* variable can be *both*!

For a practical example (in MyHDL) on how this can be useful, see:
     http://myhdl.jandecaluwe.com/doku.php/cookbook:jc2

How to solve the confusion? Replace the "Think hardware" paradigm with
"Understand your compiler" (the compiler being the synthesis tool).
Similar to what good software engineers do, you have to understand what
type of coding styles are handled efficiently by the compiler, even if
at first you don't exactly understand how.

Once you do that the confusion disappears and a whole new world of
elegant coding solutions becomes available. And you even start to
understand how the compiler works - it's not *that* hard after all :-)

Jan

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

On May 5, 4:41 am, Edmond Cot=E9 <edmond.c...@gmail.com> wrote:
> 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

The ideas are the same, but Atom lags behind Bluespec on nearly every
front.  Atom has:

- no support for multiple clock domains
- no assertions
- no input language support for SystemVerilog or SystemC
- incomprehensible HDL code generation
- minimal circuit optimization
- limited design capacity

If you are looking for a behavioral synthesis tool for professional
grade ASIC design, Bluespec is the best choice on the market.  But if
you're a hobbyist without a CAD budget, Atom provides a glimpse of the
future of IC design.

-Tom

PS: This is just speculation, but Atom's rule scheduling may be
significantly different Bluespec -- I see no mention of it in the MIT
research papers.  For those interested, Atom assigns a global, linear
priority to rules.  To maximize rule concurrency, Atom prioritizes the
rules to minimize the number of lower priority rules that write data
read by higher priority rules.  When a higher
priority rule writes data read by a lower priority rule, but not vice
versa, this forms a "sequentially composable" relationship, and
thus the two rules can execute in the same clock cycle.  In this
framework, rule scheduling becomes equivalent to the Feedback Arc Set
problem (http://en.wikipedia.org/wiki/Feedback_arc_set), where an arc
is a data dependency between two rules.

Unfortunately, many of the arcs in a rule-data dependency graph are
irrelevant, since some rules can not be enabled at the same time.  For
example, take an FSM, where the FSM is modeled with one rule for every
state:

stoplightController :: System ()
stoplightController =3D do

  state <- reg "state" 2 0
  let red    =3D constant 2 0
      yellow =3D constant 2 1
      green  =3D constant 2 2

  rule "onRed" $ do
    when (value state =3D=3D. red)
    ...
    state <=3D=3D green

  rule "onGreen" $ do
    when (value state =3D=3D. green)
    ...
    state <=3D=3D yellow

  rule "onYellow" $ do
    when (value state =3D=3D. yellow)
    ...
    state <=3D=3D red

For the stoplightController, the onRed, onGreen, and onYellow rules
will never be enabled at the same time.  Therefore, any arcs between
these rules should be removed from the rule-data dependency graph
before optimizing the schedule.  To find these mutually exclusive
rules, Atom analyzes the rule logic with it's own algorithms and with
the help of the MiniSat external SAT solver.  There's no guarantee it
finds all mutually exclusive rules, but it does a pretty good job.

On Sat, 05 May 2007 11:52:30 -0700, evilkidder@googlemail.com wrote:

> 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.

I would tend to agree. I have been working on a HDL (which is stalled
because some aspects of it don't scale well!) but explicitly declaring
registers is something that I like. From my stuff:

reg myRegister[%8]; # an eight bit register
reg myRegister[%8] = dataIn when load; # loadable register
reg myCounter[%8] = next; # 8-bit binary counter that just counts up
reg myCounter[%8] = { next when up; prev when dn; } # up/dn counter
gray myCounter = next; # gray counter that just counts up
johnson myCounter = { 0 when rst; next when up; } # guess what it does?
onehot myCounter = { async 0 when rst; next when up; } # ditto
shift reg myShReg[%8] = next when shft with myShReg[0] = serialIn; # ditto

Finally an example that creates two counters which are incremented in
different states of a state machine:

# the two counters
reg myCounterA[%4], myCounterB[%8] = { node up; next when up; }

# the state machine
reg myStateMachine[] = {
  : myCounterA.up = 1; next;
  : myCounterB.up = 1; prev;
}

Regards,

Paul.

On Sun, 06 May 2007 18:57:14 +0100, Paul Taylor wrote:

too hasty in posting....

> gray myCounter = next; # gray counter that just counts up
> johnson myCounter = { 0 when rst; next when up; } # guess what it does?
> onehot myCounter = { async 0 when rst; next when up; } # ditto

should be as: 

gray reg myCounter[%4] = next; 
johnson reg myCounter[%4] = { 0 when rst; next when up; }
onehot reg myCounter[%4] = { async 0 when rst; next when up; } 

gray, johnson, onehot provide context for the next and prev keywords
(amongst other things)

Regards,

Paul.