<ZipCPU>
Hmm ... makes me wonder why Digilent said there should be 521 horizontal refreshes per frame instead of 525. Any one know about the "right" answer for 640x480 encoding? 525 or 521 total "lines"?
<qu1j0t3>
eh well i do have a copy of the VESA standards
<qu1j0t3>
do you want me to look it up?
<ZipCPU>
qu1j0t3: Perhaps
<ZipCPU>
Part of my problem though is that I'm finding so *many* contradicting standards out there.
<ZipCPU>
Digilent claims the timings are from the VESA spec, so qu1j0t3 if you get a chance ... I'd love to know if they match.
<ZipCPU>
I wonder if those timings were bastardized for a 25MHz pixel clock rather than the actual pixel clock of the spec ...
<qu1j0t3>
ZipCPU: I get Ver. Total Time = 525 lines from VESA
<qu1j0t3>
16.683 ms
* ZipCPU
scratches his head
<qu1j0t3>
but this depends on frame rate!
<qu1j0t3>
640 x 480 x 60 Hz = 525 lines
<qu1j0t3>
640 x 480 x 72 Hz = 520 lines
<qu1j0t3>
640 x 480 x 75 Hz = 500 lines
m_w has joined #yosys
<qu1j0t3>
640 x 480 x 85 Hz = 509 lines
* ZipCPU
scratches his head some more
<qu1j0t3>
:)
<qu1j0t3>
yep, it's a minefield
<ZipCPU>
Thanks for looking that up for me.
<ZipCPU>
Now I'll know to check the standard first, before doing any more with the Video. :|
<qu1j0t3>
np
<qu1j0t3>
i probably just made the situation worse
<ZipCPU>
qu1j0t3: Not really. The sim I'm using allows any mode line to be given to it. Likewise, the VGA controller I just posted with it will work off of any mode line. (You still need to get the Pixel clock rate right in the H/W)
<Kooda>
awygle: what exactly did you wanted me to check with icetime? I don’t understand.
<awygle>
Kooda: icetime should tell you the maximum clock frequency your design will support. you should confirm that that number is >= your actual clock rate
<Kooda>
The input clock of the FPGA, or from the PLL?
<awygle>
whatever your logic is running on (in this case, from the PLL)
<Kooda>
In this case, it’s fine.
<ZipCPU>
Not sure what that means though. The design has multiple clocks, and transitions on things other than the positive edge of a clock.
<ZipCPU>
From a timing standpoint, the design is really a nightmare.
<awygle>
true. i'd expect the timing analysis to pick up the @(negedge) stuff and factor that into the overall frequency, but perhaps it's not that smart.
<Kooda>
Even without transition it doesn’t work.
<ZipCPU>
Would you expect it to handle @(negedge hsync) or @(negedge vsync)?
<awygle>
ZipCPU: *i* would expect it to, but i'm pathologically optimistic ;)
<ZipCPU>
Well, ... I'd expect the synthesis and P&R tools to "do the right thing", but timing? How would you even analyze that?
<awygle>
i'd think it'd be rolled in as combinational logic between the hsync/vsync flop and the line_counter flops
<awygle>
that's physically what's going to happen anyway
<awygle>
you might try extracting those into a synchronous edge detector though, it *is* pretty weird
<awygle>
or just an if statement in the @(posedge vgaclk) block
<Kooda>
Everything could be done at the vgaclk tick yes.
<Kooda>
It’s just counting pixels
<Kooda>
(and lines)
promach has quit [Ping timeout: 250 seconds]
heath has quit [Ping timeout: 248 seconds]
heath has joined #yosys
promach has joined #yosys
proteus-guy has quit [Remote host closed the connection]
proteus-guy has joined #yosys
danieljabailey has quit [Ping timeout: 256 seconds]
danieljabailey has joined #yosys
<promach_>
How do I check for conflicting assertions ?
eduardo__ has joined #yosys
danieljabailey has quit [Ping timeout: 264 seconds]
eduardo_ has quit [Ping timeout: 268 seconds]
danieljabailey has joined #yosys
dys has joined #yosys
proteus-guy has quit [Ping timeout: 240 seconds]
m_t has joined #yosys
dys has quit [Ping timeout: 250 seconds]
dys has joined #yosys
proteus-guy has joined #yosys
thoughtpolice has quit [Read error: Connection reset by peer]
lvrp16 has quit [Ping timeout: 272 seconds]
thoughtpolice has joined #yosys
lvrp16 has joined #yosys
danieljabailey has quit [Ping timeout: 248 seconds]
danieljabailey has joined #yosys
sklv has joined #yosys
sklv has quit [Ping timeout: 272 seconds]
pie_ has joined #yosys
pie_ has quit [Ping timeout: 250 seconds]
pie_ has joined #yosys
pie_ has quit [Ping timeout: 248 seconds]
pie_ has joined #yosys
<ZipCPU>
promach_: I think you are asking the wrong question.
<ZipCPU>
Usually conflicting assertions are easy to find ... you use the tools to get a trace and a line number of an assertion that failed.
<ZipCPU>
That makes it easy to then examine the design, together with the trace, to see what's going on.
<ZipCPU>
The more difficult task is if you have conflicting assumptions. In that case, you don't get a trace.
<ZipCPU>
The trick there is trying to figure out which assumption is the problem.
<ZipCPU>
My approach is to bisect the assumptions within my design, commenting out vast sections of them, until I can find the one that has the problem.
pie_ has quit [Ping timeout: 250 seconds]
<promach_>
ZipCPU: ok, now I am solving my assertion problems after found out which one of the two is not the right assert
<promach_>
I guess I need to comment out my assume() and restart the verification
<promach_>
I have even reduce my temporal induction length after passing the induction test
<promach_>
ZipCPU: now I realised how much time it would really take to prove a piece of code
<ZipCPU>
Good!
<ZipCPU>
You are actually making it through the process? Wow, I'm impressed! Congratulations, then.
<ZipCPU>
It's certainly not nearly as simple as simulation, now, is it? ;)
danieljabailey has quit [Ping timeout: 252 seconds]
pie_ has joined #yosys
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined #yosys
danieljabailey has joined #yosys
pie_ has quit [Remote host closed the connection]
pie_ has joined #yosys
pie_ has quit [Ping timeout: 255 seconds]
pie_ has joined #yosys
pie__ has joined #yosys
pie_ has quit [Remote host closed the connection]
pie_ has joined #yosys
pie_ has quit [Remote host closed the connection]
pie_ has joined #yosys
pie_ has quit [Remote host closed the connection]
pie__ has quit [Remote host closed the connection]
pie__ has joined #yosys
m_w has quit [Quit: leaving]
pie__ has quit [Remote host closed the connection]
pie__ has joined #yosys
pie__ has quit [Remote host closed the connection]
pie__ has joined #yosys
m_t has quit [Quit: Leaving]
<promach>
ZipCPU: still working on it, code is still not proven completely
dys has quit [Ping timeout: 252 seconds]
dys has joined #yosys
pie__ has quit [Ping timeout: 240 seconds]
m_t has joined #yosys
pie__ has joined #yosys
pie__ has quit [Remote host closed the connection]
pie__ has joined #yosys
puddingpimp has quit [Read error: Connection reset by peer]
puddingpimp has joined #yosys
Tenacious-Techhu has joined #yosys
<Tenacious-Techhu>
Anyone here manage to install icestudio on a Raspberry Pi?
<ZipCPU>
icestudio? No, but I did manage to get the icestorm toolchain to work on an RPi.
<ZipCPU>
Once I managed to get it to work, I realized how slow the Pi was and then stopped using it.
<Tenacious-Techhu>
Which Pi did you run it on?
<ZipCPU>
2B
<Tenacious-Techhu>
ZipCPU, did you use the Apio install?
<ZipCPU>
I think I installed from sources.
<ZipCPU>
I guess I'm just a touch too close to the toolchain sources, having written several bug reports ... I trust the "current" version more than any packaged version.
<Tenacious-Techhu>
In my opinion, building from sources is a job for someone who has a system that uses ECC memory, which requires a Xeon processor and a motherboard chipset to support those things.
<Tenacious-Techhu>
It's bad strategy to expect end-users to compile software.
<qu1j0t3>
it's incredibly unlikely that gcc/clang will generate a valid, but incorrect, binary in the face of a memory error. you'd be better off fretting about bugs in the program text :)
<awygle>
i don't think icestorm really has "end users" that aren't also ~developers, at least not yet
<awygle>
perhaps not developers of the toolchain but developers of _something_, and therefore comfortable with compiling from source
<Tenacious-Techhu>
FPGA firmware developers and software developers aren't really the same thing. Most FPGA development takes place on proprietary toolchains that, besides a stray bug here or there, work out of the box.
* ZipCPU
grins widely at "FPGA firmware developers and software developers aren't really the same thing"
<qu1j0t3>
Tenacious-Techhu: oh you mean things like creating production bitstreams?
<Tenacious-Techhu>
Yup. Most of the time, the guy who develops the FPGA bitstream and the guy who programs for any virtualized CPU on that FPGA are different people.
<ZipCPU>
Hmm ... in my experience (sample size of one), they were both the same person. :D
<awygle>
i mean, icestorm's not a proprietary toolchain
<ZipCPU>
... and, realistically, icecube questions are off topic.
<awygle>
since nobody's paying to make it work "out of the box", the only incentive to make it do so is basically pride of workmanship, which takes a back seat to paying work
<awygle>
ZipCPU: to be fair, he was talking about icestudio
<ZipCPU>
?? okay, now I'm confused. (Probably nothing new)
<cr1901_modern>
ran into a nice oversight I guess you call it, where ice40 is putting spi flash into deep sleep mode before xferring control to the user code
<awygle>
Tenacious-Techhu: to kind of ... recenter - did you have particular problems installing icestudio on a raspberry pi, or were you just asking whether it was a good idea?
<ZipCPU>
awygle: Thank you. I just discovered icestudio now, I wasn't aware it existed before.
<cr1901_modern>
I mean I love the RPi integration on a number of ice40 boards, but I'm not sure I'd like waiting for icestorm to finish up just to get a development environment for ice40 in a convenient form factor
<awygle>
ZipCPU: you're welcome. there's a very interesting fpga community in Spain that i'd like to connect with at some point. you may have seen #FPGAWars on twitter or elsewhere - that's them
<ZipCPU>
Not really ... I've been wondering who they were.
<cr1901_modern>
Also yosys is known to really stress test the RPi
<cr1901_modern>
(compiling it anyway)
Tenacious-Techhu has quit [Ping timeout: 260 seconds]
<awygle>
cr1901_modern: i had a (terrible) idea once to write a Yosys accelerator for ice40s, so you could program the accelerator, use it to synth+place+route your design, then replace the accelerator with the design
<cr1901_modern>
I don't even want to think about how to do a PAR IP on FPGA
<cr1901_modern>
That just makes my head hurt
<awygle>
yeah, i decided to focus on more... straightfoward efforts lol
<awygle>
i do think it's a cool idea though... maybe someday in the far far future
<cr1901_modern>
Also let's be honest, no hobbyist FPGA right now is going to give commercial CPU-based hardware a run for its money
<ZipCPU>
cr1901_modern: I can dream, right?
<cr1901_modern>
Of course! Dreaming is good
<awygle>
well it all comes down to what you want. i like the idea of having a self-contained reconfigurable computing machine
Tenacious-Techhu has joined #yosys
<Tenacious-Techhu>
awygle, sorry for the late reply; my Pi has some overly burdensome webpages open.
<Tenacious-Techhu>
Anyway, I'm having trouble either installing or using icestudio...
<Tenacious-Techhu>
And given that icestudio uses an Appimage, I'm inclined to think that I shouldn't be having trouble launching it.
<Tenacious-Techhu>
Any thoughts, awygle?
<awygle>
Tenacious-Techhu: i would watch e.g. top and see if you're getting OOM-killed when you try to launch it. i'm not too familiar with appimage but i have a possibly-erroneous impression that appimage software tends to be memory hungry
<Tenacious-Techhu>
awygle, could you be more explicit with what you are suggesting?
<awygle>
the pi is very memory-light. you might get away with allocating a swap file but that will be _even slower_ than the standard pi slowness. i'd really recommend doing development on a desktop (possibly in a VM) if possible.
<awygle>
Tenacious-Techhu: are you familiar with the OOM (out of memory) killer in Linux?
<awygle>
Tenacious-Techhu: you can run `dmesg | egrep -i 'killed process'` and see whether anything has been killed recently
zino has joined #yosys
<Tenacious-Techhu>
awygle, that does not appear to be the problem.
<awygle>
Tenacious-Techhu: well, in that case i'm afraid i don't have any further suggestions
<Tenacious-Techhu>
awygle, if an Appimage is anything like an Application Bundle, I see no reason why it should cost any more memory to launch or run.
<awygle>
Tenacious-Techhu: actually, appimage may expect a particular CPU architecture. the fact that the pi is ARM may be the issue
<awygle>
but that's pretty much speculation
<Tenacious-Techhu>
awygle, I would guess it may or may not, based on how it is built...
<Tenacious-Techhu>
Unfortunately, the documentation is terribly unclear.
<Tenacious-Techhu>
Is the icestorm toolchain still verilog only?