-
Notifications
You must be signed in to change notification settings - Fork 1
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
Smoketest: Churchroad multiply expression compiled and simulated via Lakeroad #81
Comments
2024-07-10Current step: given an egraph with primitive interfaces in it, (1) find the primitive interfaces and (2) call Lakeroad on them. Working on (1). Ah, something I messed up: I thought I needed to extract the PrimitiveInterface expressions and run them through Lakeroad. That is true, because it tells us what template to use (or in the future, allows us to generate sketch templates automatically). But I also need to extract something concrete to use as the spec. E.g. if the PrimitiveInterface was merged with a Mul expression, i need the Mul. Currently once again confused about what |
2024-07-11Oliver says that the extract_variants behavior is odd. I'm debugging now. I put in a print inside the function that's always outputtting the same thing:
Seems odd that this is always empty. The value it's being compared against is
I don't know exactly what this is. But I guess the question is, is Oh! figured it out! They were comparing I think I want to build a custom Extractor for this problem in the end anyway...I don't quite know how to use the output of extract_variants in a useful way. I'm running into what's quickly becoming a familiar issue: I have to do some things over an 2024-07-12Seems like you should be able to go back and forth between eclass ids in serialized an nonserialized egraphs based on classids. 2024-07-14Nearly have Churchroad calling out to Lakeroad. Current issue is that Verilog produced is incorrect: |
2024-07-16I'm at the stage where I've run Lakeroad and gotten a result, and I have to stick it back in the egrpah. To do so, I'm using the plugin to convert it to egglog commands. However, the call to the plugin is just failing w/o much error. It's failing in the churchroad pass itself. I'm gonna just run the plugin manually and see what's happening. Here's the issue: there's a DSP instance, but we don't have the definition of the DSP module. This means that we know what ports are connected up in the DSP, but we don't actually know what direction each of the ports is. Currently, the plugin relies on port direction, because it treats inputs and outputs differently when generating egglog code. I think the easiest solution is to just expect that all modules are fully defined, but also ensure that when we generate egglog code we don't necessarily generate all of the egglog for the referenced modules. I mean, we could also just geenrate that code as well, but it'll clutter the egraph at this point. Next thing: we need those module port input/output declarations to be fed in to the smoketest somehow, too. The real solution to this is to include the DSP48E2 semantics officially somewhere in churchroad (or have them be specified by Lakeroad, or by the user). A quicker bandaid would be to just concat the DSP definition onto the output of Lakeroad, as a hack. Ok, implemented that hack. Next issue: churchroad code being produced isn't portable. I think there's gonna be a number of this type of bug. Basically, it's not safe to just run it on the egraph, it generally expects to be run on an empty egraph already. First issue of this type: we're attempting to re-let-bind names that have already been bound. This could be fixed pretty simply by just adding a random string to the names, i suspect. |
2024-07-24Okay, I added salt. Now the issue is that the output egglog defines let bindings for inputs e.g. a. I'm wondering if we just get rid of those entirely, and instead enforce the use of something that reads the IsPort relation. I could also make it a flag on the Yosys pass to optionally make let bindings. Two other things we'll run into. First is that we always define the inputs to be Vars. That won't be right, in our case, though---instead of Vars we want something that we can union to the input eclasses. Second is that we define a let binding for the output. One question re: inputs---should they be Vars at all? They could also be Wires. What's the difference between a Var and a Wire? Wire doesn't get looked up during interpretation. Wire can't be interpreted (for now). Var implies that it's an input. Wire implies that it'll be connected to something. Should we just support both? Should we force the user to decide between them? We could also allow the user to specify an expression to union each input to -- that would probably work best in our situation, to avoid the hassle of having to generate temporary, non-clashing names for input and output exprs. |
2024-07-25So how to solve the issue of colliding let bindings on ports? Okay, I did that. Now I just need to include a way to add custom merge statements, that will merge the ports with the relevant expressions in the existing egraph. Alright, i'm nearly done with that too. might need to stop soon though. Ok, i'm figuring out how to pass in the expressions to Yosys and quoting is giving me trouble (unsurprisingly, maybe) |
2024-07-26How does the arg parser in Yosys work? See question and notes in here |
2024-07-28I think I should probably just hack this for now until the Yosys team tells me how to fix it. Basically just replace spaces with underscores on the way in. OK that worked! Woohoo! Now just have to extract a program from the egraph, convert to Verilog, and simulate. Working on the extractor now. Gonna just build an extractor that filters out all non-structural Verilog. Running into the following issue. When trying to extract a Verilog program, I found that the egraph had at least one Concat node with no children. I suspected that the children had been deleted, so I disabled the The root of this must be that there's some bad Verilog being generated somewhere, or we're translating Verilog to egglog incorrectly. How would this happen? Basically, we're generating wires that don't get unioned to anything. We should add something that detects this in the future. IT would be pretty easy to do. Found it:
This wire isn't unioned with anything. Taht's maybe unsurprising -- it's the unused portion of the output wire. It is very literally not connected to anything. No port or anything. It is, correctly, an unused wire. So how to handle this? Seems like filtering out all wires is not correct. That may have worked -- at least the current error went away. I'm now generating Verilog, but I doubt it's legal (but hoping it's close to correct). Time to simulate it and see what happens. Getting so close!!!! |
A simple first smoketest would be to use Churchroad to compile a design which Lakeroad can already synthesize by itself: a multiply narrow enough to fit on a single DSP.
Essentially, the steps are this:
(Op2 (Mul) a b)
of <18 bits.Something like
(rewrite (Op2 (Mul) a b [of a certain bitwidth]) (PrimitiveInterface (DSP <params>) a b)
PrimitiveInterface
#85The text was updated successfully, but these errors were encountered: