<awygle>
gotta love a net named "low data rate high speed output"
<pie__>
xD
<pie__>
its got redundancy!
<pie__>
(id guess)
<pie__>
or...low latency?
<awygle>
na it's just that the net was "ldr_dout" and somebody copy-pasted and changed it to "ldr_dout_HS" without thinking about what "ldr" might stand for
<awygle>
("somebody" might even be me)
soylentyellow has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
<awygle>
okay, awesome, i figured out the problem. unfortunately it is probably not solveable.
<azonenberg>
lol
<azonenberg>
gotta love those
m_t has quit [Quit: Leaving]
<awygle>
or more like "trivially solveable but i can't update the gateware at the customer site so let's see if i can work around it in software, what fun"
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
thallia has quit [Ping timeout: 252 seconds]
thallia has joined ##openfpga
rohitksingh_work has joined ##openfpga
cr1901_modern has quit [Ping timeout: 268 seconds]
<cr1901_modern>
awygle: Ty for the link. I've seen it before and find it very fascinating, but not a machine I'd personally use (e.g. programs written for that particular machine's extensions will never run on anything else)
<awygle>
cr1901_modern: fair 'nough :-)
Bike has quit [Quit: Lost terminal]
m_w has joined ##openfpga
<cr1901_modern>
awygle: Someone in #snes IRC channel just forwarded me the same link LOL. Did it go viral or something?
<awygle>
cr1901_modern: Orange Website
<cr1901_modern>
Ahhh, no wonder why I didn't see
<awygle>
a wise choice lol
<cr1901_modern>
IRC, Twitter, and forums are enough for me. I don't need to lose 10% of my lifespan to the Orange Hivemind
<awygle>
i'm glad you've found a setup that works for you!
<Xark>
cr1901_modern: I just pasted it in another channel, it is currently on Hacker News -> https://news.ycombinator.com/
<awygle>
personally i find twitter much more mentally difficult than HN most days. still trying to dial it in
<cr1901_modern>
awygle: That's fair. Twitter is the final stop on the social media express where all hopes and dreams go to die.
<cr1901_modern>
Might explain my affinity for it...
<rqou>
cr1901_modern: on a different topic, why a ym2151?
<rqou>
why not an OPL2/OPL3?
<cr1901_modern>
B/c everybody on the planet's already doing YM2612. I like the extra FM channels of the YM2151 (c.f. Any of Utabi's MDX/x68k work for really good use of the chip. Even FM drums), and
<cr1901_modern>
I don't find OPL as aesthetically pleasing
<rqou>
and why not an OPN?
<cr1901_modern>
B/c OPM was simply the chip I was most interested in at the time when Lord_Nightmare tricked me into vectorizing it.
<cr1901_modern>
s/tricked/persuaded/
<rqou>
<drama>make yet another SID emulator?</drama>
<cr1901_modern>
Look, I have 2 SIDs sitting 5 feet away from me. I've never successfully hooked them up and got them to make sound/analyze waveforms, and dealing w/ the analog stuff isn't all that appealing to me.
<rqou>
lol
<cr1901_modern>
Doesn't help they require a 12v rail
<rqou>
are they attached to a c64? :P
<awygle>
as someone who usually pays almost no attention to retrocomputing or the details of old gaming consoles, i've had reason in the last week to 1) read 6502 assembly and 2) learn about the "1chip snes"
<cr1901_modern>
No I got them as a gift in 2010
<rqou>
do the filters work? :P
<cr1901_modern>
(2:19:50 AM) cr1901_modern: I've never successfully hooked them up and got them to make sound/analyze waveforms
<rqou>
oh
<rqou>
i have three SIDs with working filters
<awygle>
jeez it's late, even at -3 hours from that timestamp. i should go to bed.
<cr1901_modern>
They sit in a drawer until I can be arsed to play with them
<cr1901_modern>
which is a shame, but... :(
<rqou>
unfortunately i still don't have a good way to play with them (they're attached to working c64s)
<rqou>
transferring data to/from a c64 is a pain in the ***
<cr1901_modern>
awygle: Where did 1chip snes come up?
<cr1901_modern>
rqou: Indeed, that's why my VIC20 sits on a shelf in the box
<rqou>
well, one of them is attached to a c128
<rqou>
these are also all disassembled waiting for me to put in a KERNAL swap
<rqou>
that i've been too lazy to do
<awygle>
cr1901_modern: something to do with speedrunning, iirc. i think somebody was asking about that vs. the new FPGA thing
<awygle>
super nt
<cr1901_modern>
kevtris is a cool guy. He spent some time in #snes after the Super NT was announced fielding technical q's/discoveries for emulation.
<awygle>
which by the way, i was pretty into until i learned about the wireless controllers
<rqou>
wait O_o kevtris is behind that fpga thing?
<cr1901_modern>
Yea... he did both the analogue nt and super nt
<rqou>
wait there are multiple FPGA things?
<cr1901_modern>
why are you so surprised :P?
<rqou>
both SNES or?
<awygle>
wait has the nt mini been around a while?
<Xark>
He has done countless arcade and console cores (for a bunch of obscure ones too).
<awygle>
or is that like "the next thing"?
<cr1901_modern>
analogue nt is a multi system emulator IIRC
<rqou>
is it based on the decap work?
<cr1901_modern>
but it started as a NES core
<awygle>
1) no 2) damn why is it 500$?
<cr1901_modern>
No, if memory serves kevtris has been incrementally working on his FPGA NES core since 2005
<Lord_Nightmare>
(and the filter is actually stable and behaves mostly sanely, unlike the 6581 where the end of the cutoff dac is actually floating to virtual ground due to not working at all any other way?)
<Lord_Nightmare>
you get some neat distortion effects because of that on the 6581, and the poor nmos inverters used as amplifiers
<Lord_Nightmare>
the 8580 uses "proper-ish" hmos-ii op-amps instead, and has a sane filter
<Lord_Nightmare>
anyway, sorry for interrupting
<cr1901_modern>
awygle: Ahhh didn't know that
* Lord_Nightmare
gone for a bit
<awygle>
apparently the "mini" is FPGA-based
<awygle>
despite its inexplicable price tag
<awygle>
(okay it's probably explicable)
moho2 has joined ##openfpga
jn__ has quit [*.net *.split]
kc8apf has quit [*.net *.split]
moho1 has quit [*.net *.split]
kc8apf_ is now known as kc8apf
pie___ has joined ##openfpga
balrog has quit [Ping timeout: 240 seconds]
renze has quit [Ping timeout: 260 seconds]
stefanct has quit [Ping timeout: 260 seconds]
pie__ has quit [Ping timeout: 240 seconds]
stefanct has joined ##openfpga
stefanct has joined ##openfpga
stefanct has quit [Changing host]
balrog has joined ##openfpga
renze has joined ##openfpga
pie___ has quit [Ping timeout: 264 seconds]
pie___ has joined ##openfpga
pie___ has quit [Ping timeout: 240 seconds]
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 240 seconds]
m_w has quit [Ping timeout: 264 seconds]
m_w has joined ##openfpga
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has quit [Ping timeout: 268 seconds]
ondrej2 has joined ##openfpga
pie_ has joined ##openfpga
<pie_>
saw a switch on display the other day, looks pretty sturdy actually
rohitksingh_wor1 has joined ##openfpga
<rqou>
pie_: the nintendo switch?
<pie_>
yea
<rqou>
help me dump the bootrom? :P
<pie_>
buy me a switch :P
rohitksingh_work has quit [Ping timeout: 240 seconds]
<pie_>
tbh im probably too noob still to help with that anyway
jn___ is now known as jn__
user10032 has joined ##openfpga
pie_ has quit [Ping timeout: 264 seconds]
moho2 is now known as moho1
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
m_t has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
rohitksingh has joined ##openfpga
soylentyellow has quit [Ping timeout: 255 seconds]
pie_ has joined ##openfpga
<whitequark>
awygle: btw any luck with MPSSE?
pie_ has quit [Ping timeout: 264 seconds]
pie_ has joined ##openfpga
eric_j has quit [Read error: Connection reset by peer]
eric_j has joined ##openfpga
<awygle>
whitequark: some. Day job went nuts. Most of that should be behind me now.
<awygle>
Still adjusting to Migen... I run tests with pytest and I'm like "wait that's it, no icarus, no verilator, just pytest?"
rohitksingh has quit [Quit: Leaving.]
SaLo has joined ##openfpga
m_w has quit [Ping timeout: 240 seconds]
eduardo_ has quit [Ping timeout: 276 seconds]
eduardo_ has joined ##openfpga
<whitequark>
heh
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
sunxi_fan has quit [Ping timeout: 240 seconds]
m_t has quit [Quit: Leaving]
m_w has joined ##openfpga
RaivisR_ has quit [Read error: Connection reset by peer]
RaivisR_ has joined ##openfpga
digshadow has quit [Ping timeout: 268 seconds]
<mithro>
Morning
<mithro>
daveshah: Is pull request #77 ready to merge?
<daveshah>
mithro: Yes, it's ready to go from my POV
digshadow has joined ##openfpga
_whitelogger has joined ##openfpga
<daveshah>
mithro: Typo - sorry - I was converting spaces to tabs, because IIRC that's what all your SLICEL code uses, in which case it's only lut.sim.v that's broken (but I think I'll tidy up the IO specification in ff.sim.v too)
<mithro>
daveshah: I don't care about what formatting we use, as long as it consistent :-P
<daveshah>
mithro: Should be fixed now
<daveshah>
mithro: I'll rename carry4_top as well now we've decided on a vaguely tolerable name, so don't merge quite yet
<mithro>
daveshah: Just one other comment
<mithro>
daveshah: We should have consistent clock/input/output/parameter ordering
<daveshah>
mithro: Yes, to the extent permissible by vendors' cell libraries at least
<mithro>
daveshah: These don't need to be compatible with vendor's cell libraries
<mithro>
daveshah: There should be a separate library which maps vendor's cell libraries onto out primitives
<daveshah>
mithro: OK. I suggest parameter, clock, input, output then
m_t has joined ##openfpga
<mithro>
daveshah: SGTM!
<mithro>
daveshah: So I think the next thing to be looking into is finishing off the rr_graph manipulation stuff
<awygle>
(i promise not to ping you about this _every_ time i'm frustrated with Diamond :P)
<mithro>
tinyfpga: ping about the above too :-P
<mithro>
daveshah: How about I put together a list of things in my vtr-verilog-to-routing repo?
<daveshah>
mithro: yes, that sounds like a good
<daveshah>
idea
<awygle>
mithro: i know you've been working on documentation for prjxray, is there a "i want to work on a new tile type, where do i start" guide?
<mithro>
awygle: Not yet
<awygle>
(no this is not me bailing on doctests i just have to wait for a p&r run and i'm looking for fun stuff to read)
<mithro>
awygle: Are you talking bitstream documentation or getting things for pnr?
<awygle>
mithro: i was thinking bitstream documentation. can you expand more on the distinction you're presenting?
<mithro>
awygle: bitstream documentation is - figuring out what the bits do
<mithro>
awygle: Then there is still work needed to describe the architecture in a format that vpr can pnr
<awygle>
mithro: okay, great, that's more or less what i figured you meant
<mithro>
awygle: They are obviously loosely related
<mithro>
awygle: But there is no reason the bitstream format has to be *sane* at all
<awygle>
mithro: sure. other than that $vendor has to work with their own format and adding insanity adds complexity.
<mithro>
awygle: Sure
<mithro>
awygle: For example the bitstream doesn't really give you a good feeling about what should be at the "routing" and what should be at the "placement" level
<daveshah>
tinyfpga and mithro: I started working out the low level format of the bitstream (frame layout, commands and CRCs) for the ecp5. Luckily it's fairly well documented by Lattice. Code is not worthy of prjtrellis yet but is a gist here atm: https://gist.github.com/daveshah1/d92024856e718efaa220cdc93751e46b
<mithro>
daveshah: That looks worthy to me
<daveshah>
I can unpack a simple bitstream to a list of bits as (bit, frame) and compare successfully to the output of Lattice's bstool dump command
<daveshah>
The python is a bit hacky still
<awygle>
daveshah: did you find the output to be something other than a giant "data" block? i looked at this briefly a while back and that was basically what i saw
<daveshah>
Basically. The main content is a single command which contains all the frames. Between each frame is a CRC16 and a 0xFF dummy byte. EBR is loaded using separate commands, but I don't parse that yet
<daveshah>
There is a lot of helpful output from various Lattice tools
<mithro>
daveshah: Going to have them all finished for me by the time I get in tomorrow? :-P
<daveshah>
mithro: I'll see what I can do :P
<daveshah>
Will open a PR on prjtrellis imminently with initial bitstream code. At least documents it
<mithro>
daveshah: Feel free to ask questions about the vpr code
mumptai has joined ##openfpga
<kc8apf>
awygle: there is a little bit of overview on http://prjxray.readthedocs.io/en/latest/ about the process. If you want to start on a new tile type, first thing is making a very simple design that uses the tile. Then figure out where that tile is in the frame address space. IOBs would be a good place to start since we haven't looked at them but I roughly know where they are in the bitstream
Lord_Nightmare has quit [Ping timeout: 260 seconds]
<awygle>
kc8apf: what i'm looking for is the rest of the sentence you just started. "First, make a bitstream using the tile, and figure out where it is in the frame address space [link to what the frame address space is/means]. Next....". does that make sense?
<awygle>
kc8apf: i basically understand "build the thing, find where it is. build lots of the thing and through $PROCESS, figure out the bits." i don't have a definition for $PROCESS, and my thoughts on followup steps are kind of vague ("build many pairs of the thing, figure out the routing bits between them" maybe?)
<kc8apf>
7-series configuration data is contained within the tiles. The addressing scheme follows the chip's internal structures
<kc8apf>
IOBs are always the first and last columns of a row which makes them easy to find
<kc8apf>
$PROCESS is more an art than science. Each subdir in prjxray/fuzzers is a TCL program that repeats a verilog module with slightly different parameters
<kc8apf>
It uses multiple tiles to try various combinations in a single bitstream generation. By recording some configuration info via TCL, we can see which bits correspond to which configuration signal names
<rqou>
i guess we won't have The Semiconductor Company until the Cheeto leaves office
<rqou>
not sure if that's a good or bad thing
<sorear>
do we know yet which of them benefits from this
<rqou>
O_o i think i just realized why
<whitequark>
do tell
<rqou>
Hock Tan is Singaporean
<rqou>
i.e. not white
<Bike>
"national security" is probably just so he can be dictatorial instead of going through the legislature.
<rqou>
what are the chances that trump thinks hock tan is chinese from china?
<sorear>
what are the chances that this is about general protectionism/race as opposed to somebody with influence having a concrete financial incentive?
<rqou>
eh, hard to say for sure
<rqou>
maybe both?
<awygle>
could easily be both. I love the dramatic language too. "uncovered" national security problems. not "decided this was probably an issue" - "uncovered", doubtless with much sleuthing
<awygle>
then again i read this headline and got confused because "qualcomm is korean" (i was thinking of Samsung) so clearly i should just shush.
<sorear>
i have no idea what nationality owns them but I know that they're a top employer in my city
<rqou>
qualcomm is an american company
<rqou>
founded by a bunch of white guys including the pretty well known andrew viterbi
<jn__>
qcom seems to have a large office in india, but that's probably irrelevant to this discussion
<rqou>
so is the non-avago broadcom btw
<awygle>
i guess if lattice is too important qualcomm definitely is
<whitequark>
lattice is too important?
<whitequark>
when did that happen
<rqou>
some chinese company (i forget which) tried to buy lattice a while back
<awygle>
sequoia or something like that? some VC firm