Hey twitterettes, I'm looking for a logic optimization tool that can create the most efficient expression that maps an n-bit input to a 1-bit output by specifying which input vectors that produce 1,0 or are allowed to be either. It takes time to do many of those by hand on paper
-
-
Replying to @OlofKindgren
The VexRiscv decoder does that as part of the elaboration process. It should be possible to extract the Simplify code as a stand-alone thing. https://github.com/SpinalHDL/VexRiscv/blob/6334f430fe1bed302733c6ea6c44f8b514f3e2c6/src/main/scala/vexriscv/plugin/DecoderSimplePlugin.scala#L175 …
1 reply 0 retweets 2 likes -
Replying to @tom_verbeure
Interesting. As a side-note, it seems
@SpinalHDL has some nifty features (like the latency matching too). This is what I like best about the new HDLs. They all bring in new ideas. Chisel's diplomacy looks pretty cool for example2 replies 0 retweets 0 likes -
Replying to @OlofKindgren @SpinalHDL
Yes, the latency matching was crucial for my ray tracer project. I wouldn’t have done the project without it.https://tomverbeure.github.io/rtl/2018/12/01/SpinalHDL-Automated-Operand-Latency-Matching.html …
3 replies 2 retweets 5 likes -
I implemented my own latency matching (along with automated pipelining) in a simple C-esque HLS tool for a FPGA AR project. The 3-4 weeks spent writing that tool easily saved me 6 weeks of RTL dev and meant creating more demo apps was much less painless.
1 reply 0 retweets 5 likes -
Interesting. In my view, I don't think we will have a new omnipresent HDL, bit rather a lot of different (graphical and textual) DSLs to help with different tasks. What you describe is super useful for DSP. Someone stitching together a SoC need a whole different toolset and so on
2 replies 0 retweets 1 like -
Replying to @OlofKindgren @fpga_dave and
But to achieve this we need better tooling and foundations. Standard libraries, a common IR that EDA tools can target directly. What
@M_Labs_Ltd and@whitequark do with nmigen is a step in the right direction in my opinion1 reply 0 retweets 2 likes -
Replying to @OlofKindgren @fpga_dave and
Other people will vehemently disagree but imo, especially given the existing (open and closed source) software ecosystem, simple Verilog is a good intermediate representation for integrating designs created from different DSLs.
1 reply 0 retweets 3 likes -
Replying to @oe1cxw @fpga_dave and
Given the existing tooling, I agree. But there are things lost in the process that makes debugging harder. This can be improved by still sticking to verilog, but my feeling is that most new HDL devs are more interested in fixing their verilog pet peeves than taking care of this
2 replies 0 retweets 0 likes
A large percentage of those issues would be solved if those verilog code generators would simply output `line directives.
-
-
Replying to @oe1cxw @fpga_dave and
Yes. And for some languages, human-readable names. Predictable names are also pretty important when you want to match constraints or attach debug probes after synthesis, so you don't have to redo that by hand every f-in time. :)
2 replies 0 retweets 1 like -
Replying to @OlofKindgren @fpga_dave and
Yes. Chisel is really bad wrt names. But a different IR wouldn't make a difference for this.
2 replies 0 retweets 0 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.