-
Notifications
You must be signed in to change notification settings - Fork 53
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
Bit splitting in Calyx. #497
Comments
Yes! It does seem like static vs. dynamic slices should probably be different primitives altogether. Static slices would get their indices as meta-level parameters, while dynamic slices would get their inputs as input wires. A good reason to separate them is that their costs are very different: static slices are effectively "free" in hardware, while dynamic slices are not. |
Would it suffice to make assign out = in[OUT_WIDTH-1:0]; |
@cgyurgyik can add some context on where you were trying to use this? |
I don't recall (TCAM maybe?), but I imagine it would be useful to make certain wires of a bus available statically. I mean a concrete example would be ISA parser, but I don't think Calyx will target that. For example,
Edit: A next step would be allowing arbitrary splicing, e.g. |
@rachitnigam I will like to tackle this issue. I suppose the plan is to go with your suggestion here? |
Hi, @anthonyabeo—I think that would be a good place to start! We would probably want to create a new, different primitive (to avoid conflicts with code that currently uses |
@sampsyo sure, that sounds good. I'll put something together and revert. |
Sometimes we only want to access a certain subset of the bits in a multi-bit bus.
std_slice
provides limited functionality in this regard.For example, in SV, we could access the
i
th bit ofin
with:in[i]
.Following this, a Calyx interface for a single-bit split primitive might look like:
This would require N individual
std_split
s to access each bit in a N-bit bus.For example, we could also add an
OUT_WIDTH
if we want to split off a subset of bits with size > 1. We would then also need to provide abegin_index
andend_index
.This also begs the question, perhaps we should differentiate between "compile-time"* splits and "runtime" splits? For example,
if I know I will always want to access the first and second bit, then this would simply be a two wire split off the bus. I would imagine this is a bit more complicated when the
index
(or indices) are determined at runtime.*There's probably better terminology that fits here
The text was updated successfully, but these errors were encountered: