[Libre-soc-bugs] [Bug 417] FSM-based ALU example needed (compliant with ALU CompUnit)

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=417

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #2)
> (In reply to Luke Kenneth Casson Leighton from comment #1)
> > cesar do you think you could do this one?  it's probably actually a really
> > easy adaptation of alu_hier.ALU because of the way that sets up self.p
> > and self.n manually
> > 
> > it just has to be very simple as an example.
> 
> Sure, I'll be glad to create a simple example. Probably more than one.

great.  we need it for a DIV FSM (fairly soon), so it's quite important.  
additional examples will be useful, however we need one just to get
started.


> The basic rules are:
> 
> 1) p.ready_o is high on the initial state, otherwise it is low.
> 2) n.valid_o is high on the final state, otherwise it is low.
> 3) The FSM stays in the initial state while p.valid_i is low, otherwise it
> accepts the input data and moves on.
> 4) The FSM stays in the final state while n.ready_i is low, otherwise it
> delivers the output data and goes back to the initial state.

that sounds about right.  if you can use nmigen with FSM, like in this
example: https://github.com/nmigen/nmigen/blob/master/examples/basic/fsm.py

ah ok so instead of just going straight into "START" in the "DONE" phase
(line 51) it would check if n.ready_i?  wait... actually... "ack" would
be renamed "n.valid_o" and "self.rdy" would be renamed "n.ready_i", right?

and at line 29, ~self.i would be called "p.valid_i" and an extra thing
added to set p.ready_o for one cycle (combinatorial), right?

-- 
You are receiving this mail because:
You are on the CC list for the bug.