although I'd also like that to support more options.).īut yeah, I'm pretty concerned about power. (similar complexity to how vlsi_mem_gen works, which I guess isn't too bad?. In that case, you'd just then need to do Verilog post-processing to add in your desired PLL or w/e. I'm not sure if that clock port will get propagated to the top module if it's only used in some child module, but I assume that's what happens or what should have happened. It doesn't go through IO, but will create an additional clock port with some clock name you specify for each module. You would need to black box a more complicated PLL though, and that's reasonable.Īlso, on the note of integer divide-by or multiply-by with clocks, I need to go back through Module, but I think you can add a clock to a module.
divider, you'd have to write up the Verilog anyways, and logically speaking, you should be able to do that just fine in Chisel (and have the divider be parameterizable !!). On that note, I don't think it needs to necessarily be a black box, since, for a typical counter-based freq. extends Data with trait Clock-like, which might be clunky.) that would then allow some kind of out.toClock function / IO support? That'd maybe initially restrict the problem to make it doable? Idk if there is anything within Chisel that would break if you allow any Bool to be out.toClock-able. I'm ok restricting clocks to only come from the output of registers (but that wouldn't really work if you wanted a clock mux), so would it be possible to add a clock-like trait to register outputs (i.e. It's a problem when Clock doesn't extend data. Yeah, I tried using clock as an IO without first checking if it was supported and Chisel barfed.
0 kommentar(er)
