<_whitenotifier-3>
[nmigen] whitequark closed issue #312: Assignment to a Record with zero-width fields generates invalid Verilog - https://git.io/JvOht
<awygle>
yeah but the ones i want to run are specifically formal based :p also formal is cool
<whitequark>
ah
<whitequark>
yeah
<awygle>
did you pick yices over z3, or is that just what sby defaulted to?
<awygle>
.. wow i thought that would take a lot longer to run, given the formal stuff
<whitequark>
i think there might have been a reason
<whitequark>
but i don't recall
<whitequark>
tr using z3 and see what happens
* awygle
tries to remember how to change the solver...
<awygle>
it seems sby defaults to yices as you're not specifying it anywhere. and switching to z3 results in... the runtimes i was expecting initially
<awygle>
everything still passes though, which is encouraging
<awygle>
usisng the abc flows also all passes at a speed somewhere between the two
<awygle>
my nuc takes a little over 9s to run with yices, 10.5s to run witih abc, and 63s to run with z3
<awygle>
i will now stop playing with this and get back to what i was originally doing >_>
<whitequark>
interesting
<awygle>
hooray, my test reaches the point of failing. always a good step.
<awygle>
do Memories support the read port being a different size than the write port?
<awygle>
looks like no
<whitequark>
unfortunately not, and neither does yosys
<awygle>
oh oof, really? that _is_ unfortunate
<awygle>
i wonder if the "Granularity" parameter of the write port could be abused to a similar effect...
<whitequark>
not quite, but yes, you could bring your own logic
<whitequark>
it wouldn't work with an async FIFO though
<whitequark>
hm, or it might
<awygle>
i am not, at present, particularly worried about the async case (since the sync case isn't working)
<whitequark>
right
<awygle>
i do not particularly want to shave this yak into the yosys codebase (not least because i'm wildly unqualified, having never hacked on it before), but i am also aesthetically displeased by hacking around this issue...
<awygle>
i think i'll just shove this work on generic asymmetric FIFOs into a branch, solve my specific immediate problem, and subscribe to the Yosys bug, then call it a night.
<whitequark>
sounds good
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/Jv3fO
<_whitenotifier-3>
[nmigen/nmigen] whitequark 9964fc6 - hdl.dsl: make `if m.{If,Elif,Else}(...)` a syntax error.
<_whitenotifier-3>
[nmigen] whitequark closed issue #284: if m.If(...): is silently dropped - https://git.io/Jv3f3
<Sarayan>
if you have the time and the inclination, I'd love to know if it's the right/optimal way of doing things
_whitelogger has joined #nmigen
<key2>
Sarayan: you're into retro gaming ?
<key2>
like furtek :)
<Sarayan>
you could say that
<key2>
so what's your final goal ?
<Sarayan>
validating my hypothesis on the konami video rendering chips to perfect the software emulation
<Sarayan>
plus, having fun
<ZirconiumX>
This reminds me a lot of my own adventures writing a clone of the PS2 PCRTC, Sarayan :P
<Sarayan>
oh?
<key2>
Sarayan: so how do you proceed ? from the die ? you try to reproduce the gateware ?
<Sarayan>
that crtc (codename CCU fwiw) I've got the traces of a LA hooked up to it, so it was easy and fun
<ZirconiumX>
I ended up having to split the vertical and horizontal parts of it
<Sarayan>
key2: a combination of pcb schematics, manuals for certain parts of the stuff, RE of the programs and in some cases LA traces
<key2>
so i guess it's just for fun
<Sarayan>
yup
<key2>
what can you do with that once you have an emulator ?
<key2>
play ? :)
<Sarayan>
amusingly, I rarely play games
<ZirconiumX>
From what I know of Sarayan, it's most likely the RE and reimplementation that they enjoy the most
<Sarayan>
yeah :-)
<key2>
and how is it different from furtek ?
<Sarayan>
furtek is furtek, and I'm myself :-P
<ZirconiumX>
Sarayan: the problem with the PS2's PCRTC is that it's Programmable
<Sarayan>
So's konami's CCU :-)
<ZirconiumX>
And generally FPGA clocks *aren't*
<Sarayan>
you can hve multiple clocks in a fpga iirc
<ZirconiumX>
So reimplementing the PCRTC requires logic clocks
<Sarayan>
what are the possible pixel clocks?
<ZirconiumX>
Effectively arbitrary
<Sarayan>
wow, that bad?
<Sarayan>
how does it manage that, pll?
<ZirconiumX>
50 MHz base clock, can be multiplied up to 4x, then a series of clock dividers
<ZirconiumX>
So yeah, probably
<Sarayan>
oh, it's a divided 200MHz clock then
<ZirconiumX>
No, because of the "up to"
<Sarayan>
oh
<Sarayan>
you can multiply by a non-integer factor?
<ZirconiumX>
No, you can multiply by 1-4
<Sarayan>
so the values are essentially 150 or 200MHz clock
<ZirconiumX>
Yeah, kinda
<ZirconiumX>
...My memory is getting terrible
<ZirconiumX>
I went back through the codebase to check
<ZirconiumX>
# The video clock VCK = (13500000 * @lc) / ((@t1248 + 1) * @spml * @rc)
<ZirconiumX>
That's 135MHz base clock
<Sarayan>
that's 13.5
<Sarayan>
which is not surprising, 13.5MHz being the standard ntsc pixel clock for digital-ish video
<ZirconiumX>
...Yeah, bad memory + really tired = brain no worky
<ZirconiumX>
I know where I got the 50MHz figure from at least
<Sarayan>
it's that the cpu external clock?
<ZirconiumX>
The GS takes in a 54MHz (NTSC) / 53.9MHz (PAL) crystal
<Sarayan>
isn't that
<ZirconiumX>
And no, the CPU external clock is 4 * 768 * 48kHz = 147.456MHz
<ZirconiumX>
Which gets stepped up to twice that internally
<Sarayan>
ah, must be the dc then
<Sarayan>
with internal x4
<ZirconiumX>
But yeah, it means you end up with CDC between the GPU and PCRTC
<Sarayan>
cdc?
<ZirconiumX>
Clock-domain crossing
<Sarayan>
ok
<Sarayan>
how fast can you crank an external sdram on the de10?
<Sarayan>
I wonder how much BW there is for the dispersed roms of an arcade pcb
<ZirconiumX>
Depending on the board you get, 150MHz is possible
<ZirconiumX>
On the other hand, DRAM is not the best thing for ROMs :P
<Sarayan>
what is?
<ZirconiumX>
You'll need to get the ROM to the FPGA-exclusive RAM
<Sarayan>
too big for that I think
<ZirconiumX>
So either upload it using the really-awkward intra-chip connection
<ZirconiumX>
Or just put the blob as a ROM in the FPGA bitstream
<Sarayan>
the rom is 10 megs typically
<Sarayan>
ain't that a little big?
<ZirconiumX>
Yeah, it is
<ZirconiumX>
But I wouldn't really call it feasible to upload it to FPGA RAM
<ZirconiumX>
You have a 4-byte link between the CPU and FPGA
<ZirconiumX>
So uploading is painful
<Sarayan>
uploading is not the issue tbh, it's the extreme amount of random access
<Sarayan>
the video itself for say overdrive is I think 5 rom random access per 6MHz pixel clock
<Sarayan>
I'm not sure that's possible with the de10
<Sarayan>
the pcb manages it because it hits 5 different roms
<Sarayan>
no common bus, etc
<Sarayan>
so it feels like it may be too much for a de10
<Sarayan>
I'm surprised boards went to sdram instead of static
<Sarayan>
looks like one can do up to 4 random accesses per 9 cycles if I understand correctly
<ZirconiumX>
It's got a burst mode for it, yeah
<Sarayan>
non-burst
<Sarayan>
precharge all, active/read for each of the 4 banks
<Sarayan>
anyway, at that point I'm only interested by running in simulation
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/Jv3R7
<_whitenotifier-3>
[nmigen/nmigen] whitequark a9da9ef - README: clarify relationship to Migen.
<whitequark>
Sarayan: seems basically fine
<whitequark>
oh, one thing
<whitequark>
you don't need to create the sync domain, generally
<whitequark>
you should not do it in any of the components of your design, and you should do it in your toplevel module (the one that actually connects to FPGA pins) only if the default domain doesn't suit your needs