开云体育

I’ve been digging into the scheduling behavior of my TagEngine implementation and could use some insight from the community on how Bluespec resolves conflicts between methods and rules, particularly with respect to granularity. In my TagEngine (FIFO-based tag management), I have: * A requestTag method that issues tags, initially from a countdown (initialTagDistributor) and later from a tagFIFO: ``` requestTag :: ActionValue UIntLog2N(numTags) requestTag = do case initialTagDistributor of Just 0 -> do initialTagDistributor := Nothing (select tagUsageTracker 0) := True return 0 Just tag -> do initialTagDistributor := Just |> tag - 1 (select tagUsageTracker tag) := True return tag Nothing -> do let tag = tagFIFO.first tagFIFO.deq return tag ``` * A retire_tags rule that recycles tags into the tagFIFO: ``` "retire_tags": when True ==> do $display "firing retire_tags" (fshow retireTag) tagFIFO.enq retireTag (select tagUsageTracker retireTag) := False ``` Triggered via a `retireTag` method writing to a wire (`retireTag :: Wire UIntLog2N(numTags)`). My question is about scheduler granularity: In the `Nothing` case of `requestTag`, there’s no write to `tagUsageTracker`, unlike the `Just` cases. `retire_tags`, however, always writes to `tagUsageTracker`. I expected the scheduler to conservatively block `requestTag` and `retire_tags` from firing in the same cycle due to the potential conflict on `tagUsageTracker`, even when `initialTagDistributor` is `Nothing`. However, my Bluesim output suggests they do fire together: ``` count : 7 retiring tag : 4 got tag : 2 firing retire_tags4 count : 8 retiring tag : 4 got tag : 4 ``` This comes from a tester using an ActionSeq: ``` |> do retireTagAction 4 requestTagAction ``` where `retireTagAction` calls `retireTag 4` and `requestTagAction` calls `requestTag`. The dumped schedule for retire_tags shows: ``` Rule: tagEngine_retire_tags Predicate: tagEngine_retireTag.whas && tagEngine_tagFIFO.i_notFull Blocking rules: (none) ``` but doesn’t mention `requestTag` (a method, not a rule). My understanding was that the scheduler operates at the rule/method level, not case-arm level, so it wouldn’t distinguish the Nothing case’s lack of tagUsageTracker writes. Yet, the simulation suggests otherwise. Here are my final questions: * At what granularity does the scheduler resolve conflicts? Does it consider runtime paths (e.g., Nothing vs. Just) or just the union of all possible resource accesses? * Why can requestTag (in Nothing) and retire_tags fire in the same cycle here? Is it because they’re sequenced within one ActionSeq rule, and tagFIFO (a FIFOF) allows enq/deq together?

You can find the snippets referenced below in the code here. In general, with respect to simulation and VCD interpretation. I’d appreciate any advice on the following: 1. What’s the best way to simulate Bluespec designs effectively? Are there tricks to make Bluesim or Verilog output more usable? 2. VCD Signal Names: My VCDs have cryptic names like: ``` $var reg 3 ; IF_tagEngine_resetTagCounter_2_BIT_3_3_THEN_ta_ETC___d30 $end ``` These seem to come from a case statement in my requestTag method: ``` requestTag :: ActionValue UIntLog2N(numTags) requestTag = do case resetTagCounter of Just 0 -> do resetTagCounter := Nothing; return 0 Just tag -> do resetTagCounter := Just (tag - 1); return tag Nothing -> do freeQueue.deq; return freeQueue.first ``` Names like that make VCDs EXTREMELY hard to use and basically useless. How can I map these back to my source code? Is there a way to get cleaner signal names? 3. Sum/Product Types in VCDs: My design uses Maybe (e.g., Reg (Maybe (UInt 3))) and vectors of registers. In the VCD, these appear as raw bit vectors. How do one decode their symbolic values (e.g., Just 2 vs. Nothing) during simulation? 4. Higher-Level Simulation: TCL feels clunky for testbenches. Has anyone integrated Bluespec with Python (e.g., via PyVerilator or cocotb) for a more modern workflow? I’m relying heavily on $display for debugging, which helps, but I’d like to leverage waveforms more effectively. Any tips or tools you recommend would be great! Theres no way $display will/scale as my design get larger. If there's currently nothing better than my flow, Bluespec urgently needs improved simulation tooling.

I'm trying to write a bus-width narrower and I'm having trouble getting the provisos to line up. My write request struct and a stripped down version of my "narrower" are as follows: typedef struct { Bit#(awidth) addr; // must be aligned, ie the low `size` bits must be 0. Bit#(TLog#(TAdd#(TLog#(dbytes),1))) size; Vector#(dbytes, Bit#(8)) data; } WriteReq#(numeric type awidth, numeric type dbytes) deriving (Bits, FShow); interface Narrower#(numeric type awidth, numeric type dbytes_wide, numeric type dbytes_narrow); interface Put#(WriteReq#(awidth, dbytes_wide)) wide; interface Get#(WriteReq#(awidth, dbytes_narrow)) narrow; endinterface module mkNarrower(Narrower#(awidth, dbytes_wide, dbytes_narrow)) provisos (Mul#(dbytes_narrow, max_beats, dbytes_wide), NumAlias#(TExp#(log2_wide), dbytes_wide), NumAlias#(TExp#(log2_narrow), dbytes_narrow), Add#(a__, log2_wide, awidth), Add#(b__, TLog#(TAdd#(TLog#(TExp#(log2_narrow)), 1)), TLog#(TAdd#(TLog#(TExp#(log2_wide)), 1))) ); ... endmodule The provisos involving a__ and b__ were suggested to bsc to get the module to typecheck. I added the other provisos to give names to various quantities. This typechecks. But when I try to instantiate it with concrete parameters: Narrower#(32, 128, 32) n <- mkNarrower; I get the following errors: Error: "Narrowing.bsv", line 73, column 8: (T0031) The provisos for this expression could not be resolved because there are no instances of the form: Mul#(TExp#(a__), b__, TExp#(c__)) The proviso was implied by expressions at the following positions: "Narrowing.bsv", line 74, column 32 Error: "Narrowing.bsv", line 73, column 8: (T0031) The provisos for this expression could not be resolved because there are no instances of the form: Add#(d__, c__, 32) The proviso was implied by expressions at the following positions: "Narrowing.bsv", line 74, column 32 Error: "Narrowing.bsv", line 73, column 8: (T0031) The provisos for this expression could not be resolved because there are no instances of the form: Add#(e__, TLog#(TAdd#(TLog#(TExp#(a__)), 1)), TLog#(TAdd#(TLog#(TExp#(c__)), 1))) The proviso was implied by expressions at the following positions: "Narrowing.bsv", line 74, column 32 Error: "Narrowing.bsv", line 73, column 8: (T0131) The numeric types `TExp#(c__)' and `128' could not be shown to be equal. This equality was required at the following position: "Narrowing.bsv", line 74, column 32 Error: "Narrowing.bsv", line 73, column 8: (T0131) The numeric types `TExp#(a__)' and `32' could not be shown to be equal. This equality was required at the following position: "Narrowing.bsv", line 74, column 32 It looks like the root problem is that bsc doesn't recognize that 32 and 128 are exact powers of two and hence a__ and c__ have to be 5 and 7 (the last two errors). (I used NumAlias#(TExp#(_),_) instead of Log#(_,_) because I only want widths that are an exact powers of two.) But I haven't been able to figure out any other formulation of the provisos that let bsc discover what it needs to know. Any suggestions would be greatly appreciated. -William

I'm making a free list in hardware - basically a LIFO that can be used to assign unique tags to bus transactions which are valid for the lifetime of the transaction. My free list module(mkTagEngine) has two methods, requestTag and retireTag. To call both methods simultaneously, requestTag needs to see what tag argument was passed to retireTag(at which point requestTag effectively "falls through" and returns the retired tag"). The only way I've found to communicate arguments between methods is `mkRWireUnsafe`. Why is this? What makes it unsafe? Should I be concerned about using unsafe? Under the hood, does FIFOF use unsafe wires as well? Here is the reference line of code: https://git.joyofhardware.com/ReferenceProjects/riscv-bluespec-classic/src/commit/ed8e0b8337539e4de4fab80883c381bf18da2a1d/bs/TagEngine.bs#L125

Is there an equivalent to mkNullCrossingWire for moving between reset domains? I'm getting BSC warnings (G0043 and G0043) about combining reset domains but I believe I have the logic worked out such that it shouldn't matter. I'd like to silence those warnings--but only exactly here where I've put the effort into thinking it though and not anywhere else where I might accidentally mess up the domains. I found the "-suppress-warnings" compiler flag, but didn't find anything to be more surgical. I'm also open to approaching this differently if this just isn't the Bluespec way. I'm trying to implement an inner module in one reset domain and an outer module in a subsuming domain that has a method to assert/release that inner module's reset and wraps the inner module's interface with one that forwards the method to the inner module when enabled and returns a failed indicator if the inner module is not enabled. The appended code is representative of what I'm trying to do. (The motivator for this is the "dmcontrol.dmactive" bit from the risc-v debug spec if that helps establish context.) I've read through the various reset related posts from the last couple years and the only ideas/suggestions I uncovered were to rewrite the code to have the "enable" be explicitly represented in logic instead of leveraging reset, to slip a dual-domain fifo between the two modules, or to write some custom verilog with appropriate annotations. I'm hesitant to use that first option because that would be a lot of repetitions of "if (is_enabled) ..." instead of just feeding it into the existing reset tree and would make it easy to accidentally miss a bit of state that needs to be reset. I'm hesitant to use the second option because it feels like a sledgehammer/fly type solution given that both modules are in the same clock domain and one reset is a strict subset of the other. Also it would add unnecessary latency to accessing the inner module. And I'm hesitant to use the third option because it seems like I'd also have to write a custom bluesim primitive and end up with a forked bsc or give up on bluesim and just use verilator. (I think--I haven't actually looked at the details so I don't know if it would be that bad or if there is an easy plugin interface I could leverage. My trepidation over leveraging BDPI turned out to be totally warranted--I now have a simple BDPI based jtag proxy that talks OpenOCD's remote bit bang protocol.) -William --- cut here --- package ResetTest; import Clocks::*; interface Inner; // Indicator that we are awake and ready to do something. method Bool awake(); // Do something critical and amazing. method ActionValue#(Bit#(32)) do_something(Bit#(32) arg); endinterface interface Outer; // Turn the inner device on or off. Transition from off to on can // take time. Check for when it is done by invoking is_on(). // Turning the device off resets it. method Action set_on(Bool on); // Returns true iff the inner device is on and ready to do // something. method Bool is_on(); // Do something, but return Invalid if the inner device isn't // ready. method ActionValue#(Maybe#(Bit#(32))) do_something(Bit#(32) arg); endinterface module mkInner(Inner); Reg#(Bit#(3)) wakeup_delay <- mkReg('1); rule wakeup if (wakeup_delay != 0); wakeup_delay <= wakeup_delay - 1; endrule method Bool awake(); return wakeup_delay == 0; endmethod method ActionValue#(Bit#(32)) do_something(Bit#(32) arg); return arg; endmethod endmodule (* synthesize *) module mkOuter(Outer); Reg#(Bool) on <- mkReg(False); Clock cur_clock <- exposeCurrentClock; MakeResetIfc inner_reset <- mkResetSync(1, True, cur_clock); Inner inner <- mkInner(reset_by inner_reset.new_rst); method Action set_on(Bool v); on <= v; endmethod method Bool is_on(); return on && inner.awake(); endmethod method ActionValue#(Maybe#(Bit#(32))) do_something(Bit#(32) arg); if (on && inner.awake()) begin let result <- inner.do_something(arg); return tagged Valid result; end else return Invalid; endmethod endmodule endpackage

I was trying to do some fancy stuff by composing an FSM using functions that return Stmt to capture sequences. Looks like I broke something along the way. Any help in understanding the error message and how to fix it is appreciated. This is with Bluespec Compiler, version 2024.07 (build b4f31dbe) Compilation message: "StmtFSM.bs", line 220, column 72: Case: [SNamed sendbytes_l102c63 [[Par_l102c63 ([Action_l103c54] [Action_l104c57] [Seq_l105c49 ([While_l106c57 [SNamed sendbits_l106c76 [[Par_l106c76 ([Action_l107c73] [SExprS _l108c77])]]]] [SExprS _l110c65])])]]] Error: "StmtFSM.bs", line 964, column 13: (S0015) Bluespec evaluation-time error: unhandled case During elaboration of `c0' at "StmtFSM.bs", line 942, column 7. During elaboration of `c1' at "StmtFSM.bs", line 943, column 7. During elaboration of `c_no_action' at "StmtFSM.bs", line 642, column 8. During elaboration of `_rfsm' at "StmtFSM.bs", line 1140, column 8. During elaboration of `fsm' at "I2C.bsv", line 134, column 21. During elaboration of `mkI2CMaster' at "I2C.bsv", line 26, column 8.

Does anyone know of a library or approach that might fill this need? I'm looking to be able to write multiple times in a cycle. For clarity, I'm trying to do something like this: import RegFile::*; module regfile_write_ports (Empty); RegFile#(UInt#(1), Bool) rf <- mkRegFileFull(); (* fire_when_enabled *) rule wr0; rf.upd(0, True); endrule (* fire_when_enabled *) rule wr1; rf.upd(1, True); endrule or even just this: import RegFile::*; module regfile_write_ports (Empty); RegFile#(UInt#(1), Bool) rf <- mkRegFileFull(); rule wr; rf.upd(0, True); rf.upd(1, True); endrule endmodule

I've been very much enjoying working in Bluespec in my spare time. I'm wondering if there is a way to work full time on it. Not exactly seeing any shops hiring for Bluespec devs!

For example - for the lines of code here, I get: ``` 2 warnings generated. In file included from 34979.c:1: ./bs//Serializer.bs:13:22: warning: missing terminating ' character [-Winvalid-pp-token] START -> 1'b0 ^ ./bs//Serializer.bs:15:22: warning: missing terminating ' character [-Winvalid-pp-token] _ -> 1'b1 ``` I know I can simply disable the pre-processor warns, but why is it so verbose in the first place?

Un-commenting the commented-out lines in the snippet below... https://git.joyofhardware.com/ReferenceProjects/riscv-bluespec-classic/src/commit/e6b002f70e76050eb60a6176f63a9a242306b6d8/bs/TagEngine.bs#L59-L71 retireTag :: UIntLog2N(numTags) -> Action retireTag tag = do let nextStackPtrUint = case stackPtr of Nothing -> 0 Just n -> n + 1 (select inUseVec tag) := False (select freeStackVec nextStackPtrUint) := tag stackPtr := Just nextStackPtrUint -- when -- tag < (reifiedNumTags - 1), -- readReg (select inUseVec tag) causes compilation to fail with: ```bash $TOPMODULE=mkSim make b_compile b_link b_sim mkdir -p build_b_sim Compiling for Bluesim ... bsc -u -sim -simdir build_b_sim -bdir build_b_sim -info-dir build_b_sim -keep-fires -aggressive-conditions -no-warn-action-shadowing -check-assert -cpp -show-schedule +RTS -K128M -RTS -show-range-conflict -p bs/:bsv/:+ -g mkSim bs/Top.bs checking package dependencies <snipped> 5 warnings generated. compiling bs//TagEngine.bs Warning: "bs//TagEngine.bs", line 43, column 8: (P0223) Definition of `counter' is not used. Error: "bs//TagEngine.bs", line 70, column 20: (T0004) Unbound variable `tag' make: *** [Makefile:103: b_compile] Error 1 ``` Is this intentional? Are you not allowed to use interface method arguments in when guards?

The `$display (fshow (tagVec !! 0))` found here is failing to compile... I tried creating my own `fshow` instance but haven't had much success... ``` rror: "bs//TagEngine.bs", line 57, column 33: (T0031) The contexts for this expression could not be resolved because there are no instances of the form: Prelude.FShow (Prelude.Reg (TagEngine.Tag numTags)) make: *** [Makefile:103: b_compile] Error 1 ```

I'm trying to figure out how to programmatically create a vector of registers in Bluespec Haskell initialized from 0..5. I think I should use mapM with mkReg next - but I'm not quite sure... Any help would be appreciated... ```bs package TagEngine() where import Vector import Util #define UIntLog2N(n) (UInt (TLog n)) data Tag a = Next (Maybe (UInt a)) interface (TagEngine :: # -> *) numTags = requestTag :: ActionValue UIntLog2N(numTags) retireTag :: UIntLog2N(numTags) -> Action mkTagEngine :: Module (TagEngine numTags) mkTagEngine = do let v :: Vector numTags Reg(UIntLog2N(numTags)) = genVector counter <- mkReg(0 :: UIntLog2N(numTags)) return $ interface TagEngine requestTag :: ActionValue UIntLog2N(numTags) requestTag = do counter := counter + 1 return counter retireTag :: UIntLog2N(numTags) -> Action retireTag tag = do counter := 0 where a = "Hello" a :: Integer a = 3 ```

Hi all! Hopefully this is the right place to post this, and I hope you don't mind a *tiny* bit of self advertising: I decided to take the initiative to create a Discord server and a SubReddit for BSC. The links are here: https://old.reddit.com/r/Bluespec/ https://discord.com/invite/QWpbuQzAtF One thing I would be interested in setting up is an IRC relay between the existing server and my new Discord server, so hopefully we can expand the community and have everyone interested in the community all be able to talk to each other! Thanks! Aistis Raulinaitis

I found some documentation on the completion buffer here: https://github.com/B-Lang-org/bsc/blob/main/doc/libraries_ref_guide/LibDoc/CompletionBuffer.tex But I haven't quite figured out a robust way to use it in Bluespec Haskell

Is there any documentation / examples on how to write testbenches in BSV? I would like to have tests that run (maybe constrained) random inputs through my modules and then compares it to a reference model. In Verilog I would have a bunch of tasks that run in an initial block that fill up arrays with inputs and expected outputs, and then always blocks that feed the inputs into the module and retrieve outputs and compare them and then emit @PASS or @FAIL at the end. I could probably hack something together using StmtFSM but it seems like it would maybe be a little clumsy, and maybe there's a better way I'm not thinking of. - Emily

Does Bluespec Haskell have an equivalent for the following Haskell code? ```hs data Size = Small | Medium | Large deriving (Eq, Show) instance Ord Size where compare Small Small = EQ compare Small _ = LT compare Medium Small = GT compare Medium Medium = EQ compare Medium Large = LT compare Large Large = EQ compare Large _ = GT ```

Okay, so clearly I'm not doing things "the intended way" otherwise I wouldn't be getting a verilog file with 1.9 million $write statements for what was supposed to be just a simple unit test for this helper function I wrote. The backstory: I set out to implement a hobby risk v core/soc because, well, who wouldn't? Got a simple clock-per-stage with no pipelining starting point with just a couple instructions going and had it printing the PC and current instruction in hex. But looking at the instruction in hex isn't very enlightening so I wrote a simple disassemble helper function so I could compare what it was reporting with the assembly I was feeding into it. At first it worked okay but as I added more and more instruction coverage to the disassembler, my compile times starting climbing. In trying to figure out why, I had the idea of compiling to verilog (was just using bluesim) and looking at the output. 1.9 million $write statements in a 500MB file! And that is after I replaced my function to turn CSR indices into names with just a hex number which dropped the compile time down from 20 minutes to 5-ish minutes. In looking at that file, it is pretty obvious that I've clearly gone well outside the expected usage patterns. (Probably because I'm mostly a software guy even though I spent 5-ish years doing FPGA work in my previous job.) Here is what appears to be going on: I've got a helper function for turning register indices into ABI names: function String reg_name(RegIdx r); Vector#(32, String) names = vec( "zero", "ra", "sp", "gp", "tp", "t0", "t1", "t2", "s0", "s1", "a0", "a1", "a2", "a3", "a4", "a5", "a6", "a7", "s2", "s3", "s4", "s5", "s6", "s7", "s8", "s9", "s10", "s11", "t3", "t4", "t5", "t6"); return names[r]; endfunction In my disassemble function, I call that 3 times with each of the rd, rs1, and rs2 instruction fields: let rd = reg_name(inst_rd(inst)); let rs1 = reg_name(inst_rs1(inst)); let rs2 = reg_name(inst_rs2(inst)); And then I have a big case-matches statement leveraging don't care bits to pick off each instruction. Excerpt: 'b0000000_?????_?????_000_?????_0110011: $format("add ", rd, c, rs1, c, rs2); 'b0000001_?????_?????_000_?????_0110011: $format("mul ", rd, c, rs1, c, rs2); 'b0100000_?????_00000_000_?????_0110011: $format("neg ", rd, c, rs2); 'b0100000_?????_?????_000_?????_0110011: $format("sub ", rd, c, rs1, c, rs2); 'b0000000_?????_?????_001_?????_0110011: $format("sll ", rd, c, rs1, c, rs2); 'b0000001_?????_?????_001_?????_0110011: $format("mulh ", rd, c, rs1, c, rs2); 'b0000000_00000_?????_010_?????_0110011: $format("sltz ", rd, c, rs1); 'b0000000_?????_00000_010_?????_0110011: $format("sgtz ", rd, c, rs2); 'b0000000_?????_?????_010_?????_0110011: $format("slt ", rd, c, rs1, c, rs2); 'b0000001_?????_?????_010_?????_0110011: $format("mulhsu ", rd, c, rs1, c, rs2); 'b0000000_?????_00000_011_?????_0110011: $format("snez ", rd, c, rs2); (I've also got let c = ", "; in scope to cut down on the number of quotes in each $format call.) The resultant verilog has this case statement represented as a large if-then-else tree where it works its way through the various fields inherent in matching against the don't-cares. But then it keeps going and adds a sequence of 32 if-then-elses for each possible value of rd and inlines the expansion of reg_name into the final string. And for each of those 32 possibilities, it then runs though the 32 possible values for rs1. And for each of those rd/rs1 combinations, it (you guess it!) fills in all 32 possible rs2 cases. All told, 32768 $write statements just to cover the "add" instruction, 1.9 million for what I have covered (rv32ima if you are curious). I tried adding some (* noinline *) attributes, but it won't let me because String and Fmt don't implement Bits and it will only noinline functions that can have their arguments/results represented as wires. The two possible alternatives I've thought of are to either explore the call-out-to-c possibilities (haven't tried anything in that area yet) or to implement a family of string utilities built using fixed size arrays of characters (something like Vector#(maxlen,Bit#(8)) with trailing nuls when the buffer isn't full or Tuple#(Bit#(Log#(maxlen+1)),Vector#(maxlen,Bit#(8)))) that could be marked noinline. So my question for the list: how should I be approaching a disassembly function that is only going to be used in debug/log output? Or is there a way to convince bsc to not be so aggressive with the inlining even though the functions in question aren't verilog port friendly? -William

I'm using CBus to create the register interface with my design, but I'm getting a lot of warnings when I try to have an RW register that's written to the FPGA side. Is this a known problem? The source code suggests that it should just prioritise CPU writes over FPGA writes, but I'm not sure if that is actually happening. Is the solution to create custom replacements for mkCBRegRW maybe with the correct specific behaviour? Two common use cases where I need this: 1) When the CPU writes 1 to a certain bit, the FPGA starts some process (if it's not running already). The bit then clears automatically. 2) The FPGA sets a bit to indicate a certain condition happened and the CPU clears it once it has seen it. I've also had one case where using the CBus like this actually caused a bug, when I wrote "rule rl_start; if(start) begin ... start <= 0; end endrule" instead of "rule rl_start if(start);", and the hardware never got triggered (which took a while to find, I never suspected it would just never trigger!). Another CBus problem I have is that CBus modules can't be synthesised, so there is some boilerplate with needing to wrap every CBus module. - Emily

I have two quick questions :) 1. Is there a way to cast between Bit #(n) and Bit #(m) with generic n and m without requiring any provisos? (automatically truncating/extending as needed) 2. How do you cast between Int #(n), UInt #(n) and Bit #(n)? The only way I could find was unpack(pack(..))...