<pepijndevos_>
This is so weird... with async reset Yosys breaks my multiplication and then optimizes it away.
fsasm has joined #yosys
proteusguy has quit [Ping timeout: 272 seconds]
<pepijndevos_>
ZirconiumX, any chance you could commit that comparator pass for me to play with?
<ZirconiumX>
pepijndevos_: yeah, give me a bit
<pepijndevos_>
I think that if that works, the PWM benchmark should be quite compact.
<pepijndevos_>
If I can get that down to a reasonable amout of chips, I think it'd be a good PoC to order that on PCB for the most elaborate fading LED thing ever.
<ZirconiumX>
pepijndevos_: I think the 181 is available in the LS family, but I can't quite tell
<pepijndevos_>
It also exists in the HC family, but no stock either.
proteusguy has joined #yosys
pie_ has quit [Ping timeout: 252 seconds]
fsasm has quit [Ping timeout: 245 seconds]
fsasm has joined #yosys
<ZirconiumX>
pepijndevos_: I pushed my comparator pass in the `cmp` branch
adjtm_ has quit [Remote host closed the connection]
adjtm_ has joined #yosys
<pepijndevos_>
thanks
fsasm has quit [Quit: Leaving]
proteusguy has quit [Remote host closed the connection]
<pepijndevos_>
ehhhhh, something is messed up
<pepijndevos_>
The upper bits of my counter just synthesize to xxxx
proteusguy has joined #yosys
<pepijndevos_>
ZirconiumX, why did you use the 74HC688_1x1EQ8 for equality but 74HC85_1x1CMP4 for gt/lt? How much did you test this? Output seems pretty wrong. Have to do some actual exam work now, will look another time.
<pepijndevos_>
Oh nvm, the 8 bit does *onl* eq, the 4 bit has more outputs
<ZirconiumX>
pepijndevos_: Because the '688 is an 8-bit equality comparator, while the '85 is 4-bit, but also does greater-than/less-than
<pepijndevos_>
cool
<pepijndevos_>
I read the datasheet title and they both said magnitude comparator.
<pepijndevos_>
Seems like for my 8 bit word, only 1 4 bit comparator gets generated :/
<ZirconiumX>
pepijndevos_: ABC is pretty good at optimising equality operations, so I don't actually use it
<ZirconiumX>
Use the '688
<ZirconiumX>
Bleh, you can figure out what I meant
<pepijndevos_>
right
<pepijndevos_>
ZirconiumX, ahhhh, I think WIDTH is incorrect? Y_WIDTH is always 1. Can you do something like max(A_WIDTH, B_WIDTH)? I'll have to think about how to handle uneven lenghts...
<pepijndevos_>
(what does this magic $pos line do)
<ZirconiumX>
Upconverts a smaller signal into a bigger signal
<pepijndevos_>
PWM with my reset changes would be less than 10 chips now!!
<pepijndevos_>
So question is... which parts should be used? Comparison definitely makes my example a lot smaller.
<pepijndevos_>
At least I don't think I'll need to make a PR for my changed to cmp as yours are identical :)
cr1901_modern has quit [Quit: Leaving.]
<pepijndevos_>
Probably worth looking closer at equality to see why it's not as efficient. My guess is a lot of 1-bit comparisons that use a full chip.
<pepijndevos_>
Ok, I should really start studying. Looking forward to pull everything together after my exam tomorrow.
<ZirconiumX>
pepijndevos_: As I mentioned, it's because ABC is much better at optimising equality tests
rrika has quit [Ping timeout: 248 seconds]
rrika has joined #yosys
citypw has joined #yosys
kraiskil has quit [Ping timeout: 272 seconds]
citypw has quit [Read error: Connection reset by peer]
citypw has joined #yosys
<pepijndevos_>
ZirconiumX, can't be much more efficient than a single chip, right? Or you mean optimizing all stuff around them? Yesterday you had some idea about variables being much more costly than constants, which seems to be the case. Can detect that and fail the techpass?
<ZirconiumX>
pepijndevos_: Yes, it can be more efficient than a single chip
<ZirconiumX>
Single bit equality tests can be XOR gates, which you can fit four in a chip
<pepijndevos_>
Right. So the trick is to gate the techpass for wide comparisons (on variables)?
<ZirconiumX>
Which I try to do
<pepijndevos_>
Hrm...
<pepijndevos_>
Oh yea, I see... and what about the variable part? I only see a fail on width, but no idea if we can even access than info.
<ZirconiumX>
We can, I believe
<ZirconiumX>
I think techmap sets CONSTMSK
<ZirconiumX>
But I'll go check
<pepijndevos_>
Oh sweet
<ZirconiumX>
Yeah, there's _TECHMAP_CONSTMSK_
citypw has quit [Ping timeout: 252 seconds]
<pepijndevos_>
(as obvious to everyone, running cadence through double X11 forwarding and a VPN is not fun at all)
kraiskil has joined #yosys
citypw has joined #yosys
adjtm has joined #yosys
rohitksingh_work has quit [Read error: Connection reset by peer]
citypw has quit [Read error: Connection reset by peer]
citypw has joined #yosys
pie_ has joined #yosys
<pepijndevos_>
ZirconiumX, I'm trying something like wire _TECHMAP_FAIL_ = (A_WIDTH <= 6 && B_WIDTH <= 6) || _TECHMAP_CONSTMSK_A_ == 0 || _TECHMAP_CONSTMSK_B_ == 0; which always fails it seems.
rohitksingh has joined #yosys
<ZirconiumX>
pepijndevos_: What are you using as your benchmark?
<pepijndevos_>
ZirconiumX, various processors. Picorv32 and VexRiscv at the moment.
<pepijndevos_>
But I'm not 100% convinced I got my parameters and conditions right. Verilog seems to be very loose with its types, VHDL would kill you if you compared a bitmask to a number like that.
<tnt>
pepijndevos_: numbers in verilog are 32 bits unsigned IIRC.
<pepijndevos_>
So uuh, is there an equivalent to {any <= '0'} or something like that? Like, whatever this is, tell me if it's all zeros.
<tnt>
== 0 ?
<pepijndevos_>
Ok great
<tnt>
you could also use assign is_x_zero = ~|x;
<pepijndevos_>
whoa, that's a funky operator.
<tnt>
~ is NOT |x ORs all the bits of x together.
<pepijndevos_>
lol, nice. Do all unary bitwise operators work like that?
<tnt>
yeh you can ^x or &x ...
<pepijndevos_>
sweet
<pepijndevos_>
ZirconiumX, I think I got it sorta working.
vonnieda_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<pepijndevos_>
It uses exactly one EQ8 in both VexRiscv and Picorv32, but it actually improves chip count at least.
vonnieda has joined #yosys
<pepijndevos_>
Ok, *another* PR sent. Studying is going well today XD (I'm running simulations in the background)
maikmerten has joined #yosys
Stary has quit [Ping timeout: 250 seconds]
zignig is now known as zignig_bedtime
emeb has joined #yosys
emeb has quit [Quit: Leaving.]
rohitksingh has quit [Ping timeout: 248 seconds]
m4ssi has quit [Remote host closed the connection]
rohitksingh has joined #yosys
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined #yosys
srk has quit [Ping timeout: 258 seconds]
Jybz has quit [Quit: Konversation terminated!]
phantomcircuit has quit [Ping timeout: 258 seconds]
Jybz has joined #yosys
srk has joined #yosys
phantomcircuit has joined #yosys
rrika has quit [Ping timeout: 248 seconds]
rrika has joined #yosys
fsasm has joined #yosys
Stary has joined #yosys
dys has joined #yosys
* ZirconiumX
pokes pepijndevos_
rohitksingh has quit [Remote host closed the connection]
<pepijndevos_>
ZirconiumX, eh?
<pepijndevos_>
Oh, stuff has been merged. Cool :)
<pepijndevos_>
ZirconiumX, I just pushed an update to the kicad branch that lets me compile pwm256.v to 5 chips and get them in KiCad.
<pepijndevos_>
oh derp, I'm an idiot... how does this even work haha
kraiskil has quit [Ping timeout: 252 seconds]
<pepijndevos_>
I'm thinking that if things work out, I could make an actual PCB over the weekend.
<pepijndevos_>
That would be so cool
<ZirconiumX>
Yeah, it would
<ZirconiumX>
Put my name on there somewhere, too, would ya?
<pepijndevos_>
Would you like ZirconiumX, Dan Ravensloft, or something else? (send me SVG? haha)
<pepijndevos_>
Also, I'm starting to think that if you'd write a RiscV with 74xx in mind, it would be waaaay less chips.
Max-P has quit [Quit: SIGSEGV]
Max-P has joined #yosys
kraiskil has joined #yosys
<pepijndevos_>
I wonder if I can modify the pwm to fade in and out and synth to 10 or less chips. Then I just have to add a clock and LED to make a breathing LED.
fsasm has quit [Remote host closed the connection]
maikmerten has quit [Remote host closed the connection]
fsasm has joined #yosys
<ZirconiumX>
pepijndevos_: ZirconiumX is fine
kraiskil has quit [Ping timeout: 245 seconds]
emeb has joined #yosys
benreynwar has joined #yosys
<benreynwar>
Hi all! I'm playing with symbiyosys for the first time. Is it normal that "Writing trace to VCD file: engine_0/trace.vcd" can take over an hour for large designs? Running the BMC only took 2 minutes since it failed at step 7 but I haven't managed to actually get a failing trace yet.
<ZipCPU>
benreynwar: Wow! Not sure I've ever tried SymbiYosys on a design where it took that long to write a VCD file
<ZipCPU>
In general, I'd advice running on a smaller design if possible
<ZipCPU>
Still, that's a new one for me
<benreynwar>
zipcpu: Yeah! I started off with a small submodule yesterday and it all went smoothly, so today I thought I'd try the top level :).
<ZipCPU>
Ahm ... how big is this top level design?
* ZipCPU
has never applied formal to an entire design
<ZipCPU>
Normally, I break a design up into smaller pieces to formally verify it
<benreynwar>
I've set all the generics to small values so that it'd only take a couple of thousand LUTs on an FPGA.
<ZipCPU>
Well ... I have applied formal to a couple thousand LUTs before ...
<ZipCPU>
One of the crossbars I applied formal to required nearly 3k iCE40 LUTs
<ZipCPU>
benreynwar: Can I try your design myself? See if I have the same problem?
<benreynwar>
It's a work project, so I'm afraid I can't share the code :(.
<ZipCPU>
I can understand
<ZipCPU>
Symbiotic EDA does sell support contracts
<benreynwar>
Yeah, I should look into that. I'm using the trial license at the moment (the design is in VHDL) and am trying to get a feel of how useful formal is for our designs.
<ZipCPU>
So, what I normally do ... I normally verify all of the "leaf modules" within the design
<ZipCPU>
That is, I verify any/all of the bus masters and bus slaves
<ZipCPU>
Separable components if you will
<ZipCPU>
I then simulate the rest
<ZipCPU>
I'm just now getting to the point where I can formally verify an interconnect--I just haven't tried my formally verified interconnect within any of my designs
<benreynwar>
I wonder if the fact that it's in VHDL could be affecting the trace dumping.
<ZipCPU>
Wow ... I hadn't thought of that
<ZipCPU>
Is it spilling information to a file during all this time? Can you use "trace -f" to see where it's at?
Jybz has quit [Quit: Konversation terminated!]
<benreynwar>
The header of the trace.vcd gets written where all the signals are defined gets written, but none of the content. The logfile.txt in the engine_0 folder is empty.
<benreynwar>
The small design I worked on yesterday worked without any problems though.
<ZipCPU>
What solver are you using?
<benreynwar>
I think your suggestion of working on the submodules is the right direction to go. Then if it is a problem with the VHDL I should see the same issue in one of the submodules.
<benreynwar>
smtbmc boolector
<ZipCPU>
Thanks ... that doesn't help though, since I haven't had any problems with boolector
<ZipCPU>
I have had problems with some of the non-smt solvers, but boolector has been one of my mainstay's
fsasm has quit [Ping timeout: 245 seconds]
<benreynwar>
So I'm going to leave this process running in the background to see if it ever writes than trace file, but move onto testing the submodules individually. As always, thanks for all your help!
<ZipCPU>
I just wish I could've helped more, and perhaps even solved your problem
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
s_frit has quit [Remote host closed the connection]