Noname_Matt has quit [Quit: Ping timeout (120 seconds)]
PyroPeter has quit [Ping timeout: 264 seconds]
citypw has joined #yosys
PyroPeter has joined #yosys
Noname_Matt has joined #yosys
Noname_Matt has quit [Ping timeout: 265 seconds]
<cr1901_modern>
daveshah: I want to revisit... is it possible to refactor building ice40 and ecp5 databases so it's possible to compile nextpnr/icestorm in constrained (2GB RAM) environments, so one can keep up with upstream without having to wait for blobs?
<cr1901_modern>
Brought to you by "I just compiled yosys on a SBC for the first time in nearly a year, and I'm dreading doing the rest"
<whitequark>
cr1901_modern: I use 4 GB of swap.
<whitequark>
it takes about a day for the entire toolchain
<cr1901_modern>
Odd, I've never had it take a day even with swap... 3 hours maybe?
<cr1901_modern>
But I didn't do an ecp5 compile
<whitequark>
i have an rpi3
<cr1901_modern>
This is an asus tinkerboard, and I've also done it on pinebook (both have 2GB RAM)
<whitequark>
yeah, rpi3 is pathologically bad
<cr1901_modern>
A clean build of the most recent commit of yosys built in 22 minutes w/ -j4
<cr1901_modern>
just now
<cr1901_modern>
before up5k features exploded :P, that would've been the bulk of the build lol
<daveshah>
I think there was an attempt to fix it in abc a while ago, but evidentally that isn't fully working
<tnt>
Yeah, I had a similar bug like a week ago or so and that got fixed by updating to master but ... well here we are :p
dys has joined #yosys
<ZirconiumX>
daveshah: This is a fun one to bugpoint. I get a "used with parameters but is not parametric" error if I don't call "hierarchy -top"; and then that requires Trellis cells to be imported, and then after this it works fine
<ZirconiumX>
Or, well
<ZirconiumX>
It works under bugpoint but not when I invoke "synth_ecp5 -abc9" manually
<daveshah>
Yes this bug is pretty much random
<daveshah>
Anything that permutes the design tends to fix it
<daveshah>
The root cause I believe comes from uneven delays in whiteboxes
<daveshah>
and how abc propagates delays (setting all the numeric values in abc9_5g.box to the same thing does make it go away)
<ZirconiumX>
daveshah: The help for synth_ecp5 doesn't actually show the commands invoked in -abc9 mode, which is a bit annoying
<tnt>
ZirconiumX: daveshah: Interesting development, if I build the exact same yosys using gcc and not clang, it works.
<daveshah>
Yosys or Yosys and ABC?
<tnt>
I would guess both ... I changed yosys Makefile and set "CONFIG := gcc" at the beginning
<tnt>
then make clean && make
<daveshah>
It might not be related - the bug is very sensitive to the exact netlist, even tiny changes tend to cause it to disappear
<daveshah>
and it could be that something changes in Yosys because of the compiler change (it shouldn't but I've seen bugs like this before)
<tnt>
but why would the compiler change the netlist ?!?
<daveshah>
I've seen things like initialiser call order before
<tnt>
Mmmm right.
<daveshah>
It's also possible that it's inside ABC
davidthings has joined #yosys
<tnt>
daveshah: Do you know how the ODDRX1F behaves ? The IDDRX1F is explicit saying Q0 is rising edge and Q1 is falling edge. But ODDR says D0 is 'first to be sent out' which would tell me it's falling edge ?
<daveshah>
I can't remember. I started looking at the Lattice sim model but it's a bit messy
<daveshah>
I think it's the same as Xilinx in SAME_EDGE_PIPELINED
<tnt>
Oh wait there is ODDRXE as well
<daveshah>
That's for the previous generation
Thorn has quit [Remote host closed the connection]
<tnt>
Heh, indeed ODDRX1F seem to be massively pipelined :/
pie_ has quit [Ping timeout: 245 seconds]
<daveshah>
Yeah, it certainly is
<tnt>
Like ... 3 clocks cycles ?
<tnt>
Is there no way to just have it like on the ice40 for instance ?
<daveshah>
Nope
freemint has joined #yosys
Thorn has joined #yosys
Duality has joined #yosys
<Duality>
hi
<daveshah>
Hi Duality!
dys has quit [Ping timeout: 240 seconds]
<Duality>
i am working on something where i have a clock input and a counter, and the output of the counter goes to one pin. but i have this weird output where the output would come to early or late, and i just can't figure out why. (at first i thought my logic analyzer wasn't fast enought so i put a scope on it)
<Duality>
would this be the place to get some help with that :)?
<Duality>
i am very new to fpga's
<daveshah>
What frequency is the counter, and where is the clock input coming from?
<Duality>
the internal hfosc
<daveshah>
and what do you mean by too early/late? by a nanosecond? by a factor of two?
<Duality>
daveshah: actually yes! a factor 2
<daveshah>
Have you connected the HFOSC to a pin and checked its frequency is correct?
<Duality>
yes
<Duality>
one moment though going to double check that :)
<daveshah>
If that is OK, I would suggest posting your code
<Duality>
i have removed the dir code and that seems to have solved it, i am just not sure why it has solved it.
<rombik_su>
Duality: What was the point of 'dir' in the first place?
<Duality>
rombik_su: i am not sure i think i tried to make a fancy counter where you could select whether it counted up or down.
<rombik_su>
Duality: Couple of small things: if(count == 15'b1) should be if(count == 16'b1)
<rombik_su>
Duality: Then it's should be input for 'counter' module perhaps
<Duality>
rombik_su: why? because 15:0 is 16 bits?
<rombik_su>
Duality: Yes. :)
<Duality>
ah
<Duality>
got to remember counting starts at 0 :)
<rombik_su>
Duality: Basically, dir was messing with your counter, erm, counting. Did you simulate this?
<Duality>
no i don't simulate maybe i should :)
<Duality>
currently have a dev board and a scope connected :P
<rombik_su>
Duality: Oh, I'm strongly suggesting you to use simulator, it'll save you a *lot* of time. Ideally, you want to get your design up and running in simulator a long before firing up any FPGA IDE.
<rombik_su>
*FPGA EDA.
<Duality>
alright :)
<Duality>
i am just playing around now but i understand that it's a good idea to simulate :)
<Duality>
thank you all for being so nice and helpfull! :)
<Duality>
i remember why i made the dir, because i wanted a counter that ran up and down so that i could pwm fade a led in and out :) and that worked fine! because with leds i couldn't really see what was going on
<Duality>
or atleast seemed to work fine. probably would have seen the issue if i simulated though :)
<rombik_su>
No problem. For dimming you'll probably need two counters - one for PWM generation and second to iterate over PWM taps.
<Duality>
rombik_su: yes that would do i think :)
<Duality>
rombik_su: what are taps? i think you meen the value where you select the duty?
<rombik_su>
Duality: Yes
<Duality>
alright
<Duality>
i'll have to leave bye! and thanks again! :)
Duality has quit [Quit: leaving]
Jybz has quit [Quit: Konversation terminated!]
fsasm_ has quit [Ping timeout: 265 seconds]
freemint has quit [Remote host closed the connection]
rombik_su has quit [Quit: Leaving]
davidthings has quit [Read error: Connection reset by peer]