N2TOH_ has quit [Read error: Connection reset by peer]
N2TOH has joined #yosys
N2TOH_ has joined #yosys
N2TOH has quit [Ping timeout: 260 seconds]
jfcaron_ has joined #yosys
craigo has joined #yosys
<ross_s>
daveshah: thanks for the feedback on the PR. I've updated the getPortTimingClass section, but when verifying the change to getPortClockingInfo I never actually seem to hit my cell->type == id_MULT18X18D check, even though I have one directly instantiated. Is there some other mechanism that causes this check to be skipped?
<ross_s>
(this check = getPortClockingInfo call)
<daveshah>
ross_s: you need to set clockInfoCount
<ross_s>
aha
<ross_s>
should it be one if any clocks are detected, or to the number of distinct clocks? It looks like the mult can have up to 4
<daveshah>
The number of clock edges affecting a pin
<daveshah>
While it is true this could be up to 4 for a DSP
<daveshah>
for now the common case of a single clock is enough imo
<ross_s>
ok, sounds good
<daveshah>
(Technically up to 8 in fact if you used the DSPs in DDR mode but even Diamond doesn't officially support this...)
<ross_s>
interesting
<ross_s>
also, do you happen to know of any good resources on the ecp5 dsp internals? I've been trying to grok some of the diamond generated code and it seems to involve both the parallel in/out and shift register in/out, but TN1267 doesn't elaborate much on how the shift setup works
<daveshah>
No, there aren't any
<daveshah>
Looking at the sim models is the only option
<daveshah>
but I've never actually looked into the shift register stuff
<ross_s>
Baffling that there is no documentation. How do Diamond users get by? Just plugging in autogenerated black boxes?
<tnt>
Yeah, I think you're supposed to use the clarity designer ...
<tnt>
Compared to the detailled docs of the ice40 (on the lower end) or the 7-series (on the upper end), the ecp5 dsp docs are definitely lacking.
<daveshah>
I think the assumption, sadly incorrect, is anyone doing complex DSP stuff has access to a Lattife FAE
<daveshah>
*Lattice
<ross_s>
I guess sim models it is then. Though, do you have to have a non-free license to generate those? I was testing out diamond yesterday and it wouldn't deign to open the simulation wizard
<daveshah>
You can just look at the Verilog all the DSP related stuff isn't encrypted
<daveshah>
in the cae_library folder of the install
jfcaron_ is now known as jfcaron
<ross_s>
good to know. hopefully I can use those for verliator as well
<daveshah>
No, they use a load of sim stuff that probably breaks in Verilog
<daveshah>
should work in icarus though
<daveshah>
s/Verilog/Verilator
<tnt>
daveshah: did you ever try the ice40 models in iverilog ? I couldn't get them to run.
<daveshah>
No, I've tried the ECP5 RAM and IO models in the past and they've worked though
<daveshah>
don't know about the DSPs
<daveshah>
I think part of the Yosys testing involved running the SB_MAC16 model in iverilog and that worked fine
dys has quit [Ping timeout: 240 seconds]
yosys-questions has joined #yosys
jakobwenzel has quit [Remote host closed the connection]
<ross_s>
hmm it looks like the timing db might be a bit sparse for the mult18x18
<ross_s>
it only has a timing for CLK0 -> P
<ross_s>
whereas the dp16kd has timings for both clocks to each output pin
<ross_s>
so currently when I call getDelayFromTimingDatabase for CLK0 and P35, it fails
<ross_s>
since it can only handle the call CLK0, P
<ross_s>
is the better approach here to expand the timing db, or try and do some ID rewriting before calling getDelay?
<daveshah>
You would need to do some rewriting
<daveshah>
This was done to stop the database from getting too massive
<daveshah>
particularly once all timings are considered
jfcaron_ has joined #yosys
jfcaron has quit [Ping timeout: 260 seconds]
<ross_s>
alright, can work with that.
<emeb>
getting an interesting error from nextpnr-ice40: ERROR: JSON module blackbox attribute value is not a number
<daveshah>
Sounds perhaps like old next nextpnr and new yosys, or vice versa?
<emeb>
Yosys 0.9+1706 (git sha1 036c46de, clang 8.0.0 -fPIC -Os) + nextpnr-ice40 -- Next Generation Place and Route (git sha1 8f28132)
<daveshah>
Try updating nextpnr
<emeb>
Will do. Thanks.
<emeb>
Hmm... that didn't fix it.
<emeb>
Will try updating Yosys
<emeb>
Updating yosys and nextpnr did not fix this
<emeb>
Yosys 0.9+2406 (git sha1 a66200ed, clang 8.0.0 -fPIC -Os) + nextpnr-ice40 -- Next Generation Place and Route (git sha1 5c6b2cba)
<emeb>
OK - this appears to be a design that has never really worked in the yosys / nextpnr flow for up5k. It's got a bunch of hairy DSP stuff in it (multiplier inferences and huge adder trees)
<daveshah>
It still shouldn't be failing this way...
<tpb>
Title: Dropbox - emeb_testcase_04-29-20.zip - Simplify your life (at www.dropbox.com)
<daveshah>
Seems to build fine here
<emeb>
Very interesting
<daveshah>
Are you sure you installed latest nextpnr-ice40?
<emeb>
I'll try rebuilding from a fresh git clone
<emeb>
previously just did a make clean / git pull /
<ross_s>
daveshah: I think I'm about done here, but have one question about how exactly the registers work - currently, I separately mark A/B/P as registered or not based on the register clock setting. 1) Is that definitely the parameter that sets whether they are registered? and 2) Is it correct to have a mixed comb & register timing, or should _any_ registered input mark _all_ IOs as registered?
<daveshah>
1) yes as far as I know
<daveshah>
2) mixed is fine, but any register means it is counted as registered in the port class