proteusguy has quit [Remote host closed the connection]
kmehall has quit [Ping timeout: 276 seconds]
kmehall has joined #yosys
gmc has quit [Ping timeout: 244 seconds]
gmc has joined #yosys
MoeIcenowy has quit [Ping timeout: 252 seconds]
MoeIcenowy has joined #yosys
<pepijndevos_>
ZirconiumX, I tried adding the 74HC30 and it does not get used at all... even if I write out ~&counter
<pepijndevos_>
But maybe I effed up the liberty logic. I just copied the 4-bit logic and extended it. I'm honestly not 100% sure if a multi-port NAND is all ANDS with a not in the end, or a tree of NANDs.
<ZirconiumX>
Hmmm...
<daveshah>
ABC often struggles to map gates with a large number of inputs, I think because of how it extracts gates in the netlist it becomes harder and harder to find a match
rohitksingh has joined #yosys
<daveshah>
AIUI it would be a tree of ANDs with a not at the end
<pepijndevos_>
Ah, I guess it's that one identity where A+B=(A*B)' or something like that
<pepijndevos_>
DeMorgan
<pepijndevos_>
Yea, so if I'm not mistaken the inverters and nor is the same as an and gate, so daveshah is correct. Will make PR.
<pepijndevos_>
Yosys did *not* like my attempt to explain it a JK flip-flop btw haha
GoldRin has joined #yosys
celadon has quit [Ping timeout: 258 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
GoldRin has quit [Ping timeout: 245 seconds]
GoldRin has joined #yosys
<pepijndevos_>
What's the deal with pmux2shiftx and shregmap? Which one do I want for mapping to a 74xx shift register?
<daveshah>
If it is a fixed length shift register, you will want shregmap followed by a custom techmap rule
<pepijndevos_>
Cool.
<daveshah>
For variable length shift registers, running pmux2shiftx first will allow a few more coding styles to be mapped but is not essential
<pepijndevos_>
What is a pmux even hehe
<daveshah>
parallel mux
<pepijndevos_>
But I think I want shregmap indeed
<daveshah>
pmux has one-hot (ish, anyway) select inputs
<pepijndevos_>
"The generated shift register will be of type $__SHREG_DFF_[NP]_ and will use the same interface as the original $_DFF_*_ cells."
<pepijndevos_>
Ehhhh, how does one SHREG have the same interface as a chain of DFF? In particular not 100% sure how it works with serial/parallel input. A chain of flip-flops would support parallel output, and maybe parallel input, right?
<ZirconiumX>
pepijndevos_: Because a SHREG (shift register) *is* a chain of DFFs
<pepijndevos_>
sure sure, just in terms of verilog interface.
<daveshah>
Most FPGA shift registers have one input and one or two outputs (some have a fixed and variable length output)
<daveshah>
You might be able to use the "tech" feature of shreg to add some custom mapping rules for sipo at least
<tnt>
Anyone knows what trying to call a task in a 'for' loop seems to not work at all ? Are you not supposed to do that ? (this is test-bench code)
<pepijndevos_>
Hmmm, as far as I can tell you can only set it to xilinx or greenpack, or you mean patch yosys to support a tech 74xx option? XD
<daveshah>
Yes, patch yosys
<pepijndevos_>
For counter extraction that goes both ways, yes, but for a very specific feature for a target that so far only 2 people care about, hmmm, let's just stick to fifo for now.
<pepijndevos_>
I'll probably bug you about the counter pass later hehe
alexhw has quit [Remote host closed the connection]
alexhw has joined #yosys
<pepijndevos_>
Seems the 74AC164 is the most common/available type
<pepijndevos_>
How does the enable thing work in shregmap?
rohitksingh has joined #yosys
<pepijndevos_>
And uuuh, does it matter where in the process I run shregmap and the techpass? Seems I broke everything...
<pepijndevos_>
Basically now I have mostly lower-case things at the end.
<pepijndevos_>
Uhm, ok, fixed that, but not a single shift register is initiated.
<daveshah>
So you will want a general techmap first, then shregmap, then a techmap for shift registers
m4ssi has quit [Remote host closed the connection]
<pepijndevos_>
assign led = counter[0];
<pepijndevos_>
counter <= {1'b1, counter[7:1]};
<pepijndevos_>
always @ (posedge clk)
<pepijndevos_>
Is that a reasonable shift register?
<pepijndevos_>
Doing this after that tells me it converted no shift registers:
<daveshah>
I think so
<pepijndevos_>
techmap -map +/techmap.v
<pepijndevos_>
shregmap -maxlen 8 -clkpol pos
<pepijndevos_>
techmap -map ../74_shreg.v
<pepijndevos_>
Converted 0 dff cells into 0 shift registers.
<daveshah>
What is the full code?
<daveshah>
You might also need a opt_clean after the first techmap
<pepijndevos_>
Hm, will try and then make a paste, or just commit all the broken stuff to a branch.
<pepijndevos_>
no change
<pepijndevos_>
DERPPPPPPP
<pepijndevos_>
I had initialised the counter...
<pepijndevos_>
Ok, so it works, but has very limited applications. Basically you can't do a parallel read/write or initialise/reset it.
<pepijndevos_>
The chip has a global reset and enable, is there any way to expose that?
<daveshah>
The enable can be used with -enpol to shregmap
<daveshah>
Resets aren't supported as no FPGA shift register I know supports reset
<pepijndevos_>
What if you do -match $_DFFSR? hehe
<daveshah>
It might work, but I wouldn't rely on it
<daveshah>
It's possible some nasty combinations like self resetting shift registers could missynthesise
<pepijndevos_>
alright
<pepijndevos_>
eh, I'm not even sure what code to write to make it want an enable.
<pepijndevos_>
I thought I'd wrap the shift in an if, but that just make DFF with MUX
lutsabound has joined #yosys
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Remote host closed the connection]
dys has quit [Ping timeout: 252 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 246 seconds]
<daveshah>
You probably need a dff2dffe to turn DFF with MUX into DFFE
lutsabound has quit [Quit: Connection closed for inactivity]
<pepijndevos_>
Oh wait, the second one undoes the dffe, why is that ZirconiumX?
<pepijndevos_>
Ah I guess because our DFF are much more area efficient
<pepijndevos_>
Eh.. 74377 seems fine to me. I mean it's half the pins of the 7416374, but it's also half the pins ;) (so chip count is worse, but area is about the same, except now with extra muxes)
<daveshah>
In any case you want to be running dff2dffe, particularly with unmap-min-ce, after doing a generic techmap run
<pepijndevos_>
Why *with* unmap-mince? Doesn't that go back from dff to dff+mux?
<daveshah>
Yes, if ce is used less than a certain number of times
<daveshah>
Because each chip shares ce between 8 DFFs
<daveshah>
You probably want to do the unmap after mapping shift registers
<pepijndevos_>
ah I see, so what it does is that if there are 5 DFFE with one clock enable, it'll not make a whole chip for that.
<pepijndevos_>
Well, removing the mince made the shift register enable work. Althoug weirdly enouhg, it makes a NOT gate and a PP rather than a negative enable. Well, fine with me. Only thing I need to figure out is the correct order of things.
dys has joined #yosys
<pepijndevos_>
Eh... ZirconiumX as far as I can tell, the unmap-mince makes everything just worse. Saves about 700 chips total by removing it.
voxadam has quit [Read error: Connection reset by peer]
voxadam_ has joined #yosys
<pepijndevos_>
huh... why is there a lowercase $dff in my output...
Jybz has quit [Quit: Konversation terminated!]
daddesio has joined #yosys
fsasm has quit [Ping timeout: 272 seconds]
vonnieda has joined #yosys
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]