<mithro>
daveshah: If you get a chance, it would be good to investigate what is going on with the LUTs - they don't seem to want to render in Yosys for some reason...
<daveshah>
Sure, I'll try and take a look
RaivisR__ has joined ##openfpga
RaivisR_ has quit [Read error: Connection reset by peer]
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 256 seconds]
Bike has joined ##openfpga
xdeller_ has joined ##openfpga
xdeller has quit [Read error: Connection reset by peer]
jn__ has quit [Ping timeout: 240 seconds]
jn__ has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
jn__ has quit [Quit: leaving]
jn__ has joined ##openfpga
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 260 seconds]
user10032 has joined ##openfpga
<mithro>
daveshah: Morning?
<mithro>
daveshah: Your commit messages leave something to be desired :-P
<rqou>
“This is pretty significant. Nerve agents such as sarin and VX need to be made in a laboratory. It is not an insufficient task. Not even the so-called Islamic State could do it.”
<rqou>
um, aum shinrikyo did it
<rqou>
i love how LE loves to bluff
<daveshah>
mithro: hey
<mithro>
daveshah: So, I think we are about to be blocked on the current carry4 stuff
<daveshah>
mithro: I can look at that this evening
<daveshah>
mithro: the reason the LUTs render dodgy BTW is because their init value is zero so there is no logic
<mithro>
daveshah: Great!
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 264 seconds]
<daveshah>
mithro: yes, the only other option is to change the Yosys behaviour though
<mithro>
daveshah: Why is it empty?
<daveshah>
mithro: Because the modules are empty from Yosys's point of view (e.g. they have blackbox as an attribute, for example)
<daveshah>
mithro: and Yosys will error out if show is called on an empty module
<mithro>
daveshah: Is there a way to detect an empty module verse a different type of error?
<daveshah>
mithro: not that I'm aware of
<daveshah>
mithro: if there is a genuine problem with the Verilog, then the %.json targets will fail and inform you
digshadow has quit [Ping timeout: 256 seconds]
<mithro>
daveshah: I guess I'll just make the %.json targets a prereq then?
<daveshah>
mithro: yes, that works
<daveshah>
mithro: I've fixed the mux output naming and VPR seems to be happy at least. Any more CARRY4 work will IMO require changing how we approach modes and I doubt I'll get that done this evening.
<mithro>
daveshah: I had already fixed the mux output naming I thought?
<daveshah>
mithro: That's really weird
<mithro>
daveshah: Yeah - I think we need to change how we are doing the modes?
<mithro>
daveshah: Oh - not on the slicel pb_model apparently...
<daveshah>
mithro: Yes. I think for now string parameters with a set of modes in an attribute is the way to go. AFAIK most vendor tools tend to use string params rather than enums to select functional modes
<mithro>
daveshah: Yeap
<mithro>
daveshah: For the LUTs, should we just be marking them as black boxes?
<daveshah>
I'm not sure. From a P&R point of view that's what they are, but I think for synthesis it's not needed.