Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use DriveVoid typeclass instead of Default for underscored circuits #25

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

t-wallet
Copy link

See clash-lang/clash-protocols#92. Feel free to suggest different different names for the typeclass/functions.

src/Circuit.hs Outdated
instance (Void a) => Void (Signal dom a) where
driveVoid = pure driveVoid

instance Void (DFM2S a) where

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this? I can see in the code addDef could be used for a Forward, But when does this happen?

Copy link
Author

@t-wallet t-wallet Jul 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The examples do not only contain function like this:

fstC2 :: Circuit (Signal domain a, Signal domain b) (Signal domain a)
fstC2 = circuit $ \ab -> do
  (a, _b) <- idC -< ab
  idC -< a

But also functions like this:

unfstC3 :: Circuit (DF dom a) (DF dom a, DF dom b)
unfstC3 = circuit $ \a -> do
  ab <- idC -< (a, _b)
  ab' <- idC -< ab
  idC -< ab'

So you can easily create an empty stream if you need it.

src/CircuitNotation.hs Outdated Show resolved Hide resolved
@martijnbastiaan
Copy link
Collaborator

Void is a fairly widespread concept. Maybe DriveVoid or Sink? Though the latter clashes with the "idle sink" in clash-protocols.

@t-wallet
Copy link
Author

Void is a fairly widespread concept. Maybe DriveVoid or Sink? Though the latter clashes with the "idle sink" in clash-protocols.

Sink is inaccurate, because we may have a Void source as well. I'll rename it to DriveVoid

@t-wallet t-wallet changed the title Use Void typeclass instead of Default for underscored circuits Use DriveVoid typeclass instead of Default for underscored circuits Jul 25, 2024
@martijnbastiaan
Copy link
Collaborator

After thinking about this for a little bit: it seems to me that this abstraction isn't quite right. We'll end up with situations where multiple protocols use the same type (e.g., Signal dom Bool) with only one implementation possible. I therefore think the right type class is:

class DriveVoid a where
  driveVoidFwd :: Fwd a
  driveVoidBwd :: Bwd a

However, this means clash-protocols will have to change its definitions to circuit-notation, or circuit-notation will have to change its. AFAIK the differences are limited to:

type family Fwd a
type family Bwd a

-- vs

class Protocol a where
  type Fwd (a :: Type)
  type Bwd (a :: Type)

and

newtype Circuit a b = Circuit { runCircuit :: CircuitT a b }
type CircuitT a b = (Fwd a :-> Bwd b) -> (Bwd a :-> Fwd b)

-- vs

newtype Circuit a b = Circuit ((Fwd a, Bwd b) -> (Bwd a, Fwd b))

@lmbollen
Copy link

lmbollen commented Dec 3, 2024

If we rewrite it to:

class DriveVoid a where
  driveVoidFwd :: Fwd a
  driveVoidBwd :: Bwd a

We might want to consider adding a possibility to stall the pipeline:

class DriveVoid a where
  driveVoidFwd :: Fwd a
  driveVoidBwd :: Bwd a
  driveVoidBwdNack :: Bwd a -- needs better name?

Then we could drop the IdleCircuit typeclass in clash-protocols

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants