<tpb>
Title: A signed multiply verilog code using row adder tree multiplier and modified baugh-wooley algorithm · GitHub (at gist.github.com)
<sxpert>
ZipCPU: am progressing at a good pace here. small question though, what's the proper way to optimize a state machine ?
<ZipCPU>
sxpert: Normally the tools will do that for you
<ZipCPU>
But the answer is also state machine dependent
<ZipCPU>
The biggest thing you can do is to reduce the size of the state space
<sxpert>
ZipCPU: yeah, I saw that, but it takes a while to reduce all states
<sxpert>
ah, so recode the states with smaller numbers. ok
<ZipCPU>
Well ... yes/no
<ZipCPU>
Smaller size, but it may use more signals
<ZipCPU>
Many synthesizers will recognize a state machine, and automatically switch the encoding to a one hot encoding
<ZipCPU>
... where there's one signal that's high for every possible state in the space
<ZipCPU>
I like to optimize my state machines by working my way through my always blocks, and trying to minimize the number of input wires needed to determine the input of any FF
<sxpert>
so, instead of having one extra large always @(posedge clk), make plenty of tiny ones ?
emeb has joined #yosys
<sxpert>
or have I misunderstood?
<ZipCPU>
sxpert: No, you aren't misunderstanding me
<ZipCPU>
That's what I do all the time. It's a style of mine, but that's why I do it
<sxpert>
leads to smaller things ? or just a writing style ?
<sxpert>
ah, clearly I'm doing something wrong ;)
<sxpert>
I'm getting an insult about combinatorial loops...
<ZipCPU>
It sort of goes over my thoughts on logic minimization
* shapr
snickers at "byte the bullet"
<sxpert>
ZipCPU: yeah, I have read it, but I suspect this may come at a later stage, as I want something functional first
* ZipCPU
offers shapr a .45, in case he wants to try it
* ZipCPU
figures a 0.45 is roughly an 0x73 in "byte" form
AlexDaniel has joined #yosys
* sxpert
learns that sometimes things declared as reg should be wires
<ZipCPU>
Inputs should always be declared as wires, ex: input wire i_clk;
<ZipCPU>
Outputs from submodules should always be declared as wires
<ZipCPU>
Anything with an assign statement should always be declared as a wire.
<shapr>
ZipCPU: I prefer 9mm, easier to fund for practice
* ZipCPU
tries to convert 9mm to a byte representation
<shapr>
heh
* ZipCPU
figures a 9mm in "byte" form is roughly an 8'h5b
<shapr>
oh man
lutsabound has joined #yosys
supervacuus has joined #yosys
m4ssi has quit [Remote host closed the connection]
supervacuus has quit [Quit: Page closed]
FL4SHK has joined #yosys
gsi__ is now known as gsi_
m4ssi has joined #yosys
lutsabound has quit [Quit: Connection closed for inactivity]
rohitksingh has quit [Remote host closed the connection]
<emeb>
ZipCPU: what's the rationale for "Outputs from submodules should always be declared as wires"?
fsasm_ has joined #yosys
<emeb>
I guess you mean they need to be wires in the higher level module.
<ZipCPU>
emeb: Yes, that's exactly what I mean
<ZipCPU>
If module top has module sub beneath it, then within module top sub's outputs need to be declared as wires
<ZipCPU>
Within module sub, they can be declared as either--depending on how you want them to behave
<emeb>
Makes sense. I remember long ago we had some Verilog tools that wouldn't let you take a reg straight out of a module. You had to assign it to a wire before going out.
<ZipCPU>
My flavor of Verilog is rather ancient ... I'm surprised, though, I didn't realize there was something more ancient :D
<emeb>
ZipCPU: Well, this was like 25yrs ago. :P
<ZipCPU>
.... and? ;)
<emeb>
heh
<emeb>
VHDL has something like that - it won't let you use an output signal in the module that creates it. You have to reassign it to something else.
<emeb>
don't know what the advantage of that is from a language standpoint.
<daveshah>
It avoids the issue that reading an `output` has different behaviour to reading an `inout`
<daveshah>
iirc VHDL also has a `buffer` type that behaves like a Verilog `output`
<emeb>
Hmm... never used that.
<emeb>
Speaking of strange languages - did anyone here ever use a language called "Module Compiler"? This was something that Synopsys acquired & sold for a while back in the late 90's. I got pretty good at using it for DSP stuff. It looked sort of like Verilog but did all the pipeline balancing and much of the math at a high level.
<emeb>
I suspect that today a lot of what it did is handled in plain Verilog through more advanced inference, but it was like magic at the time.
leviathanch has quit [Remote host closed the connection]