<pie_>
when i say "research grade software" what does that make you think
<nats`>
sotware which work on only one machine
<nats`>
the one of the guy who wrote it
<lain>
^
<pie_>
i figured :/
Bike has joined ##openfpga
inoor has joined ##openfpga
Hootch has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
X-Scale has joined ##openfpga
m_w has joined ##openfpga
<qu1j0t3>
nats`: haha
<qu1j0t3>
i mean, "accurate"
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
pie_ has quit [Changing host]
pie_ has joined ##openfpga
inoor has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
m_t has joined ##openfpga
massi has quit [Remote host closed the connection]
inoor has joined ##openfpga
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
lexano_ has joined ##openfpga
lexano has quit [Ping timeout: 260 seconds]
_whitelogger has joined ##openfpga
azonenberg_work has joined ##openfpga
pie_ has quit [Ping timeout: 272 seconds]
<azonenberg>
lolol
<azonenberg>
new xcell daily blog from xilinx
<azonenberg>
... about coolrunners
<azonenberg>
apparently they're committing to at least 7 more years of product support
<azonenberg>
Sounds like the perfect time to work on a toolchain :p
<azonenberg>
Give people an alternative to ISE
* azonenberg
might start playing with initial support after work
lexano_ has quit [Ping timeout: 240 seconds]
<lain>
lol
<azonenberg>
lain: when me and rqou were testing, gp4par + yosys ran in well under a second and it took 10+ seconds to ISE-build even a simple coolrunner bitfile
<azonenberg>
of course my toolchain is massively smaller too
<lain>
hah
<rqou>
azonenberg: your board has the ft232? not 2232?
<azonenberg>
rqou: Yes, the 232H (not the 232R) has jtag support
<azonenberg>
no additional uart but i only needed one channel
<azonenberg>
back in the day when the 1st gen 2232 came out, it was the only part with jtag support
<azonenberg>
so everyone used it
<azonenberg>
the next gen 2232 kept the MPSSE, but they also added it to the next gen 232
<rqou>
oh so this does have mpsse
<rqou>
oh wait shit is this high-speed?
<azonenberg>
yes
<rqou>
my crappy rework job might not quite work in this case
<azonenberg>
usb can survive a lot of abuse
<azonenberg>
its probably fine :p
<azonenberg>
And you can do jtag up to 30+ Mbps with the 232h
<rqou>
ok it did enumerate
<rqou>
also btw if you don't practice enough your pcb rework skills really do decay
<azonenberg>
I know, this is why i'm making this practice board
<rqou>
i haven't really done rework in over a year and wow i can feel it
<rqou>
also, apparently your connector did have superglue or something on it and was a huge pain to try and reuse
<rqou>
so now serial #3 has a "captive cable" :P
<azonenberg>
lol
<azonenberg>
i was like, i thought i had glued things after i started having problems
<rqou>
not enough apparently
<rqou>
i've so far had a good experience with the hirose zx micro connectors
<rqou>
but since you're moving away from usb anyways, meh
<azonenberg>
i have yet to have an rj45 break off on me :p
<rqou>
also, is this a new PID? "Future Technology Devices International, Ltd Dev board JTAG (FT232H based)"
<azonenberg>
Yes
<rqou>
i've never seen something show up as that
<azonenberg>
That's my own PID
<azonenberg>
allocated out of FTDI's vendor namespace
<rqou>
oh wow you even bought a PID?
<rqou>
that's so much effort :P
<azonenberg>
FTDI gives you up to 8 for free to use with their VID
<azonenberg>
on request
<azonenberg>
the only caveat is, you have to use them with their silicon and VID
<azonenberg>
I had a good reason
<azonenberg>
tl;dr the default PID loads the UART driver
<azonenberg>
you can blacklist the uart driver and prevent any other FTDI stuff from working in uart mode
<azonenberg>
Or you can just not use the default PID
<azonenberg>
there doesnt seem to be a good way to have multiple instances of the same PID with different drivers attached
nats` has left ##openfpga [##openfpga]
<azonenberg>
I dont know how it works on windows but this was the case on *nix
<rqou>
i thought there's a bit in the eeprom that controls whether the uart driver loads?
<azonenberg>
Not that i recall
<azonenberg>
its done by the driver with just the vid/pid before attaching
<rqou>
hmm, i definitely recall an "enable vcp" bit
<azonenberg>
a) i have never seen one used before and b) on a virtex7 board
<rqou>
btw my father recommended to try a much older ISE if cpldfit is being stupid
<rqou>
anyone want to volunteer? :P
<azonenberg>
lool
<azonenberg>
i'd rather just black-box it at this point
<azonenberg>
i mean we're 99% of the way to knowing what everything does
<rqou>
yeah i'm going to finish having lunch and then try it
<azonenberg>
At this point we can probably black-box those two bits easily enough
<azonenberg>
At which point we have a full xc2c32a bitstream spec
<azonenberg>
i want to delayer a 2c64a soon and figure out that bitstream
<rqou>
oh wait that virtex-7 board is "only" USD$7k?
<rqou>
that's pretty "cheap" :P
<azonenberg>
i was more commenting on the coolrunner
<azonenberg>
like, xilinx must still like them
inoor has quit [Ping timeout: 246 seconds]
<azonenberg>
also the 64a...
<azonenberg>
Looking at the JED file it seems like the ZIA is 16 bits and bit #12 always goes from 1 to 0 when the row is used
<azonenberg>
then exactly two other bits do as well
<azonenberg>
conjecture: might be a 2-level mux
<azonenberg>
i'll investigate more as time permits
<azonenberg>
So bit #12 is likely the inverted "drive high" bit that supplies a default state when not used
<azonenberg>
I'll take a quick look at the top metal layer of one under the scope when i get off work
<rqou>
it's interesting how the zia stuff doesn't seem to be data-driven unlike the rest of the flow
<azonenberg>
what do you mean
<azonenberg>
there's files related to it in the ISE dir
<rqou>
the zia bit encoding doesn't seem to be in the xbr/data directory
<azonenberg>
But i didnt want to look at them
<azonenberg>
Oh
<rqou>
the zia layout is though
<azonenberg>
I havent looked at the actual bit coding
<rqou>
but it only maps to "Gn" values
<azonenberg>
I'll look at the 64a zia in more detail after i get out
<azonenberg>
i feel like i can probably black box it knowing what i do about the 32a
<azonenberg>
the 128 and larger, less so
<azonenberg>
But again lets finish the 32 first
<rqou>
oh nice openocd finally fixed this problem: "Support for new FTDI based adapters can be added competely through configuration files, without the need to patch and rebuild OpenOCD. "
<azonenberg>
:)
<rqou>
i was definitely super tired of that problem
<azonenberg>
rqou: oh also
<azonenberg>
i just realized
<azonenberg>
you dont need to use 56 product terms
<azonenberg>
You just need to AND more than 40 inputs into a single p-term
<azonenberg>
Because then you run out of ZIA-PLA routes
<azonenberg>
and that cannot be optimized around
<rqou>
ahh right
<rqou>
hmm still eating food right now, brb :P
<azonenberg>
So, basically set up 21 input pins and a 21-bit shift register
<azonenberg>
and AND the FFs and signals with each other
<azonenberg>
you're guaranteed to get a combinatorial feedthrough
<azonenberg>
actually you dont even need a shreg
<azonenberg>
just do
<azonenberg>
input wire [20:0] din;
<azonenberg>
reg[20:0] din_ff;
<azonenberg>
input wire clk;
<azonenberg>
always @(posedge clk) din_ff <= din;
<azonenberg>
if(din == din_ff) blah
<azonenberg>
or more like
<azonenberg>
assign dout = (din == din_ff)
<azonenberg>
that's a 42-bit input comparison that should use an extra path through the zia
<azonenberg>
and should easily fit in a 2c32a
<azonenberg>
Also starshipraider host board arriving friday
<azonenberg>
i know what i'm doing this weekend :D
<rqou>
nope, tried what you suggested and cpldfit still thinks it doesn't fit
<rqou>
wow cpldfit is garbage
<azonenberg>
hmm
<azonenberg>
lolol
<rqou>
it'll be hilarious if (other than the xor gate) we can get better results than xilinx on their own parts
<azonenberg>
I think we can
inoor has joined ##openfpga
digshadow has quit [Quit: Leaving.]
<rqou>
azonenberg: even after reading the code i still don't get how your jtag mux is supposed to work
<rqou>
wow there's so much inverting, mirroring, etc going on here