<sorear>
hmm, that's roughly what I expected, but I'm surprised I don't get useful hits from "recycled chips" *sans* xc9500
_whitelogger has joined ##openfpga
Bike has quit [Quit: Lost terminal]
Patater has quit [Remote host closed the connection]
Patater has joined ##openfpga
<azonenberg_work>
whitequark: gimme a sec
<azonenberg_work>
whitequark: um, what package is this?
<azonenberg_work>
vq100?
<azonenberg_work>
tq100*
<azonenberg_work>
vq64?
_whitelogger has quit [Remote host closed the connection]
_whitelogger_ has joined ##openfpga
rohitksingh has joined ##openfpga
_whitelogger has joined ##openfpga
lovepon has joined ##openfpga
ym has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 260 seconds]
<sorear>
assumption: in FPGAs, there is typically no way to reset distributed RAM or block RAM to the configured value without reloading the entire configuration (i.o.w the configured data is not stored separately from the live memory array)
<sorear>
for SRAM FPGAs that is; flash-based products need some reset mechanism
<rqou>
whitequark: ping?
<rqou>
tl;dr of the xc9500xl flashing?
<azonenberg_work>
sorear: correct
<azonenberg_work>
there is not
<azonenberg_work>
you write directly to the live memory
<azonenberg_work>
for dff's in some parts the reset value is stored separately and you can reset to it (using the global reset)
<sorear>
hmm. not sure what the deal is with ice40's "brams read zero for a few microseconds after global reset, despite being initalized by the bitstream"
<azonenberg_work>
weird indeed
<rqou>
# Conjecture (high confidence): 6x4 L-field is expanded into a 32-bit word by padding each
<rqou>
# into 4 8-bit chunks.
<rqou>
# 6-bit field part up to a 8-bit word part by adding zeroes as MSB. All words appear to separate
<rqou>
yes, this is correct
<rqou>
the "6 bits" part controls the PLA
<rqou>
and the rest of the bits control macrocells
<rqou>
anyway, whitequark you seem to be entirely on the right track
<rqou>
just need to help me finish up project14 after that :P
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 250 seconds]
jevinskie has joined ##openfpga
rohitksingh has joined ##openfpga
jevinski_ has quit [Ping timeout: 245 seconds]
jevinski_ has joined ##openfpga
rohitksingh has quit [Ping timeout: 268 seconds]
jevinskie has quit [Ping timeout: 250 seconds]
<travis-ci>
whitequark/Glasgow#138 (master - 8fecd8d : whitequark): The build has errored.
<whitequark>
ok, does nextpnr want an *installed* libtrellis?
<whitequark>
or the source tree?
<whitequark>
doesn't seem to work with either...
<daveshah>
nextpnr needs the source tree which it uses to do the chipdb build
<whitequark>
ah, i fucked up shell
<whitequark>
ok
<daveshah>
you also need it installed to have ecppack to make bitstreams from text config
<daveshah>
~ in the path by any chance?
<whitequark>
yes
<whitequark>
exactly
<daveshah>
that one caught out clifford too :D
<daveshah>
ad Lattice and Trellis - I believe Edmund is demoing it to their CTO soon (and I know edmund mentioned this here before, so it's hopefully not secret)
<whitequark>
niiiice
<whitequark>
daveshah: /home/whitequark/Projects/nextpnr/gui/ecp5/mainwindow.h:44:18: warning: 'new_proj' overrides a member function but is not marked 'override'
<daveshah>
whitequark: create an issue, I'm sure micko will sort that. I'm not so sure about the gui side of things
<whitequark>
ok
lovepon has quit [Ping timeout: 260 seconds]
<whitequark>
thanks!
<daveshah>
no problem! please report any issues you have
<cr1901_modern>
Why are FTDI breakout boards so expensive? Shikra is also $50 but with a 2x10 header
<whitequark>
yep something like that
<whitequark>
the cost could be *way* lower for castellated module
<daveshah>
no level translation either
<whitequark>
no level translation
<whitequark>
possibly no power sequencing even
<whitequark>
no onboard 3V3 Vreg
<whitequark>
just 1V2
<whitequark>
single side assembly of course
<whitequark>
daveshah: not sure how many I/O
<whitequark>
probably all 16 but then it's fixed on 3V3
<whitequark>
or, I could do 8 but it's variable volage
<whitequark>
voltage*
<whitequark>
could also do a weird number like 12
<whitequark>
software's flexible enough
<cr1901_modern>
8 + variable voltage would make a decent logic analyzer module in a small package
<sorear>
what's the advantage of the module over the current rev(B,C) approach?
<whitequark>
sorear: cost, size, emebeddability
<whitequark>
module could be probably more like $20 than $50
<whitequark>
it would be under 5x5 cm i think
<whitequark>
probably more like 3x4
<whitequark>
at most
<whitequark>
and it could be drop-in solderable
<whitequark>
i *might* be able to squish it into a wide pdip footprint
<cr1901_modern>
fwiw, dip technically goes to 900mils
<whitequark>
i mean the dips that are like one thumb width
<whitequark>
no idea how many mils is that
<whitequark>
old eeproms and such
<cr1901_modern>
600mils
<whitequark>
this form factor is reasonably common
<whitequark>
ok
<whitequark>
sure
<cr1901_modern>
You'll never see a modern IC with 900mil
<sorear>
other than software compat, why should I, a board-maker, use this instead of running the fx2 by itself as a jtag-usb bridge?
<cr1901_modern>
just saying it's breadboard-doable :P
<whitequark>
sorear: because it's more than jtag
<whitequark>
it can do any bus you want within the limits of pin count
<sorear>
my board only has jtag, so i don't care about other interfaces
<whitequark>
also, fx2 is extremely slow
<whitequark>
well then don't use it?
<whitequark>
not cost effective
<whitequark>
if you only have jtag just break it out on 2.54
<cr1901_modern>
sorear: Depending on your level of masochism, you're prob better off making your own one-off application or making an openocd backend
<cr1901_modern>
or maybe jtaghal, idk how stable that is today
<whitequark>
daveshah: wow, openocd is sloooooow
<whitequark>
8 seconds
<whitequark>
and... it ignores adapter_khz?
<whitequark>
what?
<daveshah>
ah, there was frequency in the svf file
<daveshah>
I copied the template from the Lattice tools
<whitequark>
ah right
<daveshah>
probably should remove that though
<daveshah>
2 seconds without it
<whitequark>
>adapter_khz 60000
<daveshah>
1.3 seconds at 10MHz
<whitequark>
works for me
<whitequark>
not sure what's the ecp5 maximum
<whitequark>
let me check
<daveshah>
25MHz is working nicelyt
<daveshah>
0.9 seconds
<daveshah>
as is 40
<sorear>
66MHz SCM, 50MHZ SPCM
<daveshah>
guess the limit of the ftdi might be hit first
<whitequark>
SCM?
<whitequark>
SPCM?
<whitequark>
ftdi is up to 60 MHz iirc
<sorear>
max tck 25MHz
<daveshah>
oh
<whitequark>
oh serial
<sorear>
whitequark: "ECP5 and ECP5-5G sysCONFIG Usage Guide" §6
<whitequark>
ah, datasheet page 88, too
<sorear>
chip-level RE question: what's the actual fastest you can configure a -25 in SPCM? if /BUSY is never asserted by the chip it could be done in about 10ms
<whitequark>
ECP5 and ECP5 sysCONFIG
<whitequark>
sounds like propane and propane accessories
<daveshah>
If you play with Diamond enough, you find that the ECP5 was originally going to be the ECP4
<whitequark>
huh
<whitequark>
daveshah: whats the state of pcie
<whitequark>
roommate wants an uhhhhh
<whitequark>
xqd card reader
<daveshah>
whitequark: the SERDES fuzzing is done
<daveshah>
I need to do the nextpnr stuff, but I there are a few things I want to sort out first
<daveshah>
improved clock constraint/multiclock
<daveshah>
moreover I might refactor the bitstream stuff
<whitequark>
niiiiiiice
<whitequark>
so SERDESes work?
<whitequark>
i can like... stab the eye?
<whitequark>
write a FOSS PHY?
<daveshah>
haven't tested as nextpnr isn't done yet
<daveshah>
that would only be a day or two's work to get that running now
<daveshah>
happy to do that if it starts blocking anyone
<daveshah>
would love to have the FOSS PHY though!
<whitequark>
well i wanna that
<whitequark>
so do it please :P
<daveshah>
sure, will do it next week :D
<whitequark>
sweet
<sorear>
there was a comment here or elsewhere to the effect that you may have to write a lot of PHY code, because the lattice serdes is much raw-er than what litepcie expects
<whitequark>
sure
<whitequark>
that sounds like fun
<sorear>
agree
<daveshah>
yes, I think most of the foss pcie work assumes a hard pcie core (so arguably cheats)
<daveshah>
lattice give you little more than 8b10b, alignment and comma detection
<whitequark>
oh, i actually get that?
<whitequark>
wow
<whitequark>
that's easier than i expected
<daveshah>
yup
<whitequark>
can probably port migen there first
<cr1901_modern>
_florent_ already did it for litex
<daveshah>
yup
<whitequark>
mh
<whitequark>
why not upstream?..
<cr1901_modern>
Because sb0
<cr1901_modern>
?
<whitequark>
what sb0?
<whitequark>
that doesnt say anything
<whitequark>
oh
<cr1901_modern>
Nvm...
<whitequark>
it's in litex
<whitequark>
so not in misoc
<whitequark>
but in migen
<cr1901_modern>
Adding Trellis was also on my todo list, but _florent_ beat me to it, I want to test it to make sure I can run it on Windows, then back port to migen, then back back port any changes sb0 wants to litex
<cr1901_modern>
to keep parity between the two in some misguided hope they'll become one again at some point
<whitequark>
hm
<whitequark>
well i don't care about litex
<whitequark>
so i am not going to port stuff to it in the first place
<cr1901_modern>
The trellis backend in litex is mostly copied from the icestorm stuff
<cr1901_modern>
Honestly, it's easier for me if you just let me do it. You seem happy w/ the icestorm backend in migen. That's mostly my work based on what rjo wanted.
<whitequark>
ok
<cr1901_modern>
I'll do that today.
<cr1901_modern>
daveshah: Prepare for a number of PRs if trellis doesn't work on Windoze :)
<daveshah>
cr1901_modern: I believe Miodrag has got Trellis on Windows working
<daveshah>
(github mmicko)
<cr1901_modern>
Will tinyfpga EX (proto) work with Trellis?
<cr1901_modern>
it's the only ECP board I have
<cr1901_modern>
Err, let me rephrase
<cr1901_modern>
"have you ever tested tinyfpga EX?"
<daveshah>
cr1901_modern: yes, a while ago
<daveshah>
but the tinyfpga programmer has been nothing but pain for me and I managed to brick my Ex board
<daveshah>
on the ecp5
<cr1901_modern>
daveshah: Join the club... that bug should be fixed now
<cr1901_modern>
it won't let you rewrite the bootloader
<whitequark>
lol the bootloader
<whitequark>
i thought that sounds like a bad idea
<cr1901_modern>
I mean it saves parts
<daveshah>
but an STM32 is <<1$
<cr1901_modern>
daveshah: That's not what I mean. In my case I despise schem capture, so less parts == more likely I won't ragequite :P
<sorear>
why bad idea
<daveshah>
sorear: there is no protection in the gateware against bricking it
<daveshah>
and the 1mm pitch connector on the Ex for jtag means unbricking is a pita
<daveshah>
haven't got round to it yet
<sorear>
i assume the bootloader won't overwrite itself and the only way you can have a problem is if you load a user design that pokes the flash
<daveshah>
no, it can be bricked by a bug in the programming software
<whitequark>
lol
<whitequark>
why is there no gateware protection exactly
<whitequark>
not even a bit that needs a magic sequence to be set
<whitequark>
that allows programming all flash
<daveshah>
the programming software in fact tries to brick the Ex boards by default at the moment - but does at least warn you
<daveshah>
the interface is very low level, so afaik the gateware doesn't even know that you are doing a write or what address you writ eto
<cr1901_modern>
Simple gatware protection could be as simple as "assert WP if not in range of user gateware"
<whitequark>
no
<whitequark>
thats not how WP works
<whitequark>
WP prevents changes to SR
<daveshah>
but atm it just passes bytes from USB to SPI anyway
<whitequark>
SR has WP for certain blocks
<whitequark>
also thats kinda dumb
<cr1901_modern>
SR?
<sorear>
it would take a miniscule amount of logic to snoop the SPI traffic and lock the bus on out of range writes or unknown commands
<cr1901_modern>
Shift Register?
<daveshah>
sorear: not if you want to cover all the different erase commands an SPI flash might have
<daveshah>
and the calculation to work out if they will or won't erase a certain address
<sorear>
daveshah: "or unknown commands"
<daveshah>
it would have to be a whitelist
<sorear>
you have a whitelist, and any command unknown to the bootloader = immediate stop
<whitequark>
sorear: even simpler
<whitequark>
just make it a TLV
<whitequark>
read/write+length+data
<whitequark>
this is like 100 lines in mgen
<cr1901_modern>
TLV?
<cr1901_modern>
too many TLAs
<sorear>
beats TLPs
<whitequark>
type length value
<daveshah>
makes sense
<daveshah>
I think tinyfpga is rewriting the bootloader in migen
<daveshah>
I know he wanted to solve some reliability issues and improve the timing so it works on the up5k
<whitequark>
right
<cr1901_modern>
daveshah: In any case, tinyfpga EX is what I have on hand, so that's what I'm testing :). I don't plan to add it to migen just yet (the UCF wasn't finalized. Hell I don't actually remember if I have a UCF at all for my proto)
<sorear>
why isn't that information in the .v file?
<cr1901_modern>
ahhh okay, so each backend uses the "native" format of UCF
<daveshah>
sorear: because that's how things normally work
<daveshah>
info in the .v file was really just a hack that stayed too long
<sorear>
daveshah: i know everyone does it, it still seems idiotic
<cr1901_modern>
sorear: It's really not portable code to put that stuff in the v file either
<daveshah>
not if you have multiple board revisions to deal with
<daveshah>
the ulx3s is particularly bad for that
<daveshah>
I think there are already three revisions of that with small changes to the pinouts
<daveshah>
anyway, constraints in the verilog are still supported (as with most vendor tools) if you really want to work that way
<cr1901_modern>
"frontends/ilang/ilang_lexer.l:33:10: fatal error: ilang_parser.tab.hh: No such file or directory" It's gonna be one of _those_ days, isn't it?
<daveshah>
cr1901_modern: just do a clean -fdx
<daveshah>
there was some renaming at one point
<cr1901_modern>
that just removed my tags files too :P
<whitequark>
wow, there is a ton of clocking
<cr1901_modern>
(nbd... I just did a backup this morning)
<whitequark>
daveshah: dont recommend clean -dxf.
<whitequark>
either -df or -dx
<sorear>
i recommend -dnx
<daveshah>
whitequark: what do you mean by clocking?
<whitequark>
daveshah: reading TN1265 now
<whitequark>
this is a massive document and ti doesn't even count SERDESes...
<daveshah>
yeah, most of that stuff is still in the "fuzzed but not in nextpnr" category
<daveshah>
I'll gradually by chipping away at that as part of my uni project
<daveshah>
but the first step of that is improving timing analysis & constraints
<whitequark>
thats ok i dont think i actually need any for now
<whitequark>
just good to know they're there
<daveshah>
analysis of multiple clock domains separately is starting to work now
<daveshah>
the ecp5 is certainly a lot more complex clocking-wise than the ice40
<cr1901_modern>
daveshah: Please tell me the environment.sh is optional if you're just _running_ trellis
<sorear>
which tool is that? nextpnr? opentimer?
<daveshah>
cr1901_modern: only needed for fuzzing
<daveshah>
sorear: nextpnr
<sorear>
can I do timing analysis of a bitstream, or is it inherently linked to p&r?
<daveshah>
sorear: In theory you could, but reading a bitstream is still WIP
<daveshah>
one day we do want nextpnr to read ASC files. istr someone did do a bit of that, but I don't think it's finished
<sorear>
wasn't there at one point a xray/trellis flow where you converted verilog to bitstreams then back to a netlist and did formal equivalence checking?
<daveshah>
that was in icestorm
<daveshah>
it includes a tool to go from an ice40 bitstream to behavioural verilog
<daveshah>
we don't have anything like that for xilinx or ecp5 yet
<sorear>
imo we should eventually
<cr1901_modern>
post-synthesis simulation?
<daveshah>
sure
<daveshah>
more important for that is just to have nextpnr spit out a post-PnR json file
<daveshah>
that Yosys can just turn back to Verilog
<daveshah>
the problem with bitstream to Verilog is it does need a bit more work
<sorear>
I think yosys can do write_verilog after synth all by itself
<daveshah>
yes, but if you want post-packing that doesn't help
<cr1901_modern>
daveshah: Is pytrellis _supposed_ to take 3.5GB of cc1plus to compile?
<daveshah>
cr1901_modern: that is doubtless the glory of boost python and c++ templates
<daveshah>
It's just set as a requirement on SymbiFlow and I don't have permission to change it
<cr1901_modern>
Ahh
<daveshah>
Doesn't stop me merging though
<cr1901_modern>
mmicko: Ever see this problem? C:/msys64/mingw64/x86_64-w64-mingw32/include/unistd.h:67:10: error: '_chsize' was not declared in this scope
<cr1901_modern>
(I'd like to add that io.h indeed declares _chsize)
<cr1901_modern>
(Oh right, this is for nextpnr-ecp5)
kuldeep has quit [Read error: Connection reset by peer]
<cr1901_modern>
daveshah: I'm not certain the best way to fix this, but nextpnr-ecp5 defines a header called "io.h" that appears to be shadowing a system header that's provided by Windows called "io.h"
<whitequark>
put it under ecp5/
<whitequark>
is the proper way
<daveshah>
oh, that's nasty
<cr1901_modern>
Trying to read the preprocessed output to figure out where things go wrong
<daveshah>
You can just rename it to pio.h
kuldeep has joined ##openfpga
<sorear>
isn't that why we have both "io.h" and <io.h>
<daveshah>
It that's the easiest fix
<cr1901_modern>
sorear: That's my question
<cr1901_modern>
but "" is impl-defined as to what it does
<cr1901_modern>
and the preprocessed output is definitely saying that the system <io.h> isn't being included
<whitequark>
it really doesnt have enough visual adi
<whitequark>
aid
<whitequark>
i've read it like 5 times at this point and i still nfc how the bits areactually laid out
<whitequark>
rqou: i am also impressed that you chose YET ANOTHER EOL'd device to reverse-engineer
<whitequark>
what's next, s6? :P
<gruetzkopf>
s3an
<whitequark>
no
<whitequark>
lol
<rqou>
whitequark: this is intended explicitly only for mame/mess type projects to do RE
* cr1901_modern
would like s3 RE lol
<rqou>
doing fitting for these CPLDs is kinda a pain in the ass
<whitequark>
oh
<daveshah>
istr hearing someone was doing spartan3
<whitequark>
ok
<whitequark>
what about XL?
<rqou>
xl was going to happen too
<rqou>
and yes, it doesn't have any diagrams right now
<whitequark>
not even diagrams
<whitequark>
like
<whitequark>
take a look at my xl docs
<rqou>
it kinda sorta requires you to be looking at a .jed file and the secret ise internal data files at the same time
<whitequark>
so it's not even black box re?
<whitequark>
like for my xl bitstream work i didn't even *have* ise
<whitequark>
much less lookedat its files
<whitequark>
p sure xilinx has nothing on me in this case
<whitequark>
wonder how well prjtrellis approach works out with cplds
<rqou>
oh yeah project14 is completely not black box
<whitequark>
i mean you could just lie about doing it black box, too
<whitequark>
i personally wont care
<whitequark>
wtf is programmable ground
<rqou>
it connects that output pin to ground
<rqou>
xc2c has it too
<whitequark>
wh... y
<rqou>
allows lowering the impedance to ground for reasons
<rqou>
idk, simultaneous switching outputs? signal integrity? higher fmax?
<whitequark>
hm ok
<rqou>
the xl is also different from the non-xl in that the xl does not have the wired-and in the interconnect
<whitequark>
also the bitstream layout is different?
<rqou>
it also has the bits arranged in a different pattern
<rqou>
the architecture is similar but they permuted the order in the .jed file
<whitequark>
and i assume the internal memory?
<whitequark>
do you even know how it's flashed?
<rqou>
there's a doc explaining how to flash with external vpp
<rqou>
and there's an address map file in ISE
<rqou>
just like for xc2c
<daveshah>
afaik Lattice recommend this for DDR2/3 interfaces on the ECP5 if possible
<whitequark>
no i mean
<whitequark>
jtag
<rqou>
no idea
<whitequark>
i dont care about vpp at all
<whitequark>
ok
<rqou>
whitequark: idk how possible it is to do a much more black box cpld RE
<rqou>
my experience so far is that the ISE cpld tools have almost no flexibility whatsoever
<rqou>
you basically can't control anything about where stuff gets placed
<rqou>
afaict the fitter tool doesn't even accept a "technology mapped netlist" the way fpgas do
<rqou>
it seems to do its own logic optimization in the fitter
<whitequark>
ahhh ok
<whitequark>
i see
<rqou>
unfortunately this makes it really hard to RE the interconnect
<rqou>
this might actually be easier by poking actual hardware
<whitequark>
what about using... yes
<whitequark>
exactly
<whitequark>
you have
<whitequark>
jtag
<whitequark>
you can literally feed it test patterns with INTEST
<whitequark>
and record response
<rqou>
i didn't have any hardware for project14
<rqou>
anyways, project14 is kinda low priority
<rqou>
fixing up xc2bit is more important
<rqou>
also ooo i forgot about jtag boundary scan
<rqou>
since poking it is annoying af with the tools i have
<rqou>
neither openocd nor jtaghal are convenient
<whitequark>
sure, it's trivial in glasgow
<whitequark>
i should add some support
<whitequark>
no idea what api to use...
<whitequark>
what api do you want?
<rqou>
in general, my approach to api design is to have every knob available :P
<rqou>
hence why I'm probably going to replace jtaghal
<rqou>
but idk
<whitequark>
well, you can always do tap_iface.exchange_dr() lol
<cr1901_modern>
daveshah: Oh God generating 85k.bba is taking _forever_ T_T
* cr1901_modern
says as it just finishes up
<daveshah>
it is a downside of the deduplication approach that nextpnr-ecp5 uses for its database, as it requires a full database to be built first
<whitequark>
rqou: btw what do you think about "glasgow-rpc"
<whitequark>
typed RPC interface using e.g. flatbuffers, that you can poke via rust
<whitequark>
that applets can optionally export
<daveshah>
I think clifford's plans for an approach that takes more advantage of the tile structure of the device for 7-series will be better
<rqou>
idk
<rqou>
but overall i like properly-designed RPC interfaces
<sorear>
can't you do the deduplication symbolically
<whitequark>
rqou: as in
<rqou>
because usually it avoids the incessant FFI fights
<whitequark>
jtaghal rewrite wise
<whitequark>
it feels fairly pointless to rewrite jtaghal *again*
<daveshah>
sorear: I'm sure there are all kinds of clever tricks
<daveshah>
but this way was a quick way to get something working and substantially smaller than a non-deduped db
<cr1901_modern>
daveshah: Is generating these dbs accidentally O(n^2)?
<cr1901_modern>
(or purposely*)
<daveshah>
cr1901_modern: no but it is O(n)
<daveshah>
and it should in theory be possible to get the "slow bits" to be effectively O(1) by considering the tile structure of the fpga
ayjay_t has quit [Ping timeout: 268 seconds]
<rqou>
whitequark: in general my approach to designing things seems to either be "everything is encoded only in data structures" or "everything is (compatible with being) an rpc call"
* sorear
just wants a single tool that can handle new fpga families without a recompile and is reasonably fast/compact
<rqou>
so i guess doing the latter for a jtag interface sounds good
<rqou>
xc2bit looks like the former
<cr1901_modern>
1. can handle new fpga families without a recompile 2. is reasonably fast 3. compact... pick two :)?
<rqou>
i really need to get around to writing some "autoffi" magic
<daveshah>
is handle new fpga families without a recompile really a sensible goal?
<cr1901_modern>
Idk, I wasn't actually contributing anything useful w/ that remark
<whitequark>
rqou: okay
<daveshah>
I was more responding to sorear
<sorear>
i'm not sure yet
ayjay_t has joined ##openfpga
<daveshah>
it rules out inlining, for a start
<daveshah>
it also means arch-specific code either has to be in a DSL or a shared object type arrangement
<sorear>
the small functions that you care about inlining in nextpnr look like they're arch-specific for bad reasons
<sorear>
arch-specific packers, sure
<whitequark>
daveshah: why even have DSOs in nextpnr?..
<sorear>
but the basic tile lookups could be handled the same way in 7-series and ecp5
<daveshah>
sorear: but we *want* the flexibility to explore
<daveshah>
different patterns do suit different arches
<rqou>
ok need to actually head to supercon now
<daveshah>
whitequark: we don't?
azonenberg_mobil has quit [Quit: Bye]
<whitequark>
oh
<daveshah>
well, we do use them for python, qt, etc on the default build
<daveshah>
but fully static nextpnr is possible I believe
<whitequark>
ok
<whitequark>
sure
<daveshah>
I was referring the parallel universe where nextpnr wouldn't need to be rebuilt for every arch
<daveshah>
But personally I'm happy with how things are atm in that respect
<azonenberg_work>
like, the basic idea of convolving with a sinc made sense but a lot of the fine points were tricky
<azonenberg_work>
like, what's the time unit for the sinc function?
<azonenberg_work>
eventually i figured out it was supposed to be your base (not upsampled) sample interval
<azonenberg_work>
but that was far from obvious
<azonenberg_work>
then i had some issues where the equations i found for various window functions had 0 to N as the coordinate range, with N/2 as the midpoint
<azonenberg_work>
while the sinc equation had 0 as the midpoint
<azonenberg_work>
you can imagine multiplying them didn't work as expected... :p
wpwrak has quit [Ping timeout: 240 seconds]
<rqou>
oh yeah, these are "typical implementation problems"
<azonenberg_work>
now that i understand the intended use case is upsample+LPF, it makes a bit more sense
<azonenberg_work>
Because the sinc function has zeroes at integer offsets so samples are unmodified
wpwrak has joined ##openfpga
<azonenberg_work>
Before, i was really confused because i was trying to convolve the sinc function with my base sample rate
<azonenberg_work>
and couldnt figure out how it was supposed to work because it was always the identity function
<azonenberg_work>
and when i scaled it out so that one X unit spanned many samples weird things happened :p
<galv[m]>
So I thought this entire time that xl was short for Xilinx, until this line: "the xl is also different from the non-xl in that the xl does not have the wired-and in the interconnect". What does xl mean here?
<azonenberg_work>
galv[m]: no the suffix has nothing to do with xilinx
<azonenberg_work>
xilinx part numbers are roughly structured as follows
<azonenberg_work>
X(ilinx)
<azonenberg_work>
Product line code (C=commercial, Q=military, A=automotive)
<azonenberg_work>
Generation and family code (7A = artix7, KU = kintex ultrascale, etc)
<azonenberg_work>
capacity number (bigger is better within a family, but the unit changes between families sometimes)
<azonenberg_work>
then sub-family at the end
<azonenberg_work>
so the xc9500 family is the base 5V family, the 9500XL is a die shrink to 3.3V with some other internal changes, 9500XV is a 2.5V shrink that doesnt seem to have been used much
<azonenberg_work>
finally after that speed and package info
lovepon has joined ##openfpga
carl0s has quit [Quit: Page closed]
<daveshah>
So it seems like Trellis now understands all the IOLOGIC and DQS related bits in the Diamond DDR3 example
<daveshah>
There are one or two electrical IO settings that still need work
<daveshah>
And one or two bits on the edge clock side of things that still need sorting (probably the bridge or sync primitives)
<marshallh>
neat
<marshallh>
ecp5 or ecp3?
<daveshah>
Everything I'm doing is ecp5
<marshallh>
i talked to someone who worked at lattice about why they skipped ECP4
<marshallh>
originally it was going to be pretty high-end
<marshallh>
they had some trobule with the serdes
<daveshah>
Interesting to know
<daveshah>
I've seen some stuff in Diamond about the ecp4 and always wondered
<daveshah>
I think the SERDES has been a bit of a problem throughout. Hence why they run the 5G ECP5s at a higher voltage
<whitequark>
huh
<marshallh>
meawnhile, you can run cyclone III bitstreamson cyclone 10
<gruetzkopf>
3? not only 4?
<rqou>
there's a particular 3/4/10 that all share idcode
<daveshah>
Yup
<rqou>
somebody on Twitter confirmed
<daveshah>
I've seen the prompt in quartus programmer asking to pick what part you actually have before
<daveshah>
But 3 and 4 are different process nodes
<rqou>
yeah the timings differ
<rqou>
just like max ii/iiz/v
<gruetzkopf>
_clever_
<mwk>
galv[m]: I guess X means extended, L means low voltage?
<mwk>
not that xilinx is consistent with that...
<daveshah>
I'm still surprised, tbh that altera die shrunk from 65nm to 60nm without changing the IDCODE
<daveshah>
Given a new mask set et al
<daveshah>
Given Lattice and Xilinx have different IDs for the same die even using OTP
<whitequark>
21:47 < daveshah> Given Lattice and Xilinx have different IDs for the same die even using OTP
<whitequark>
what
<whitequark>
do all fpga vendors participate in incest?!
<rqou>
yes
<rqou>
ecp5 is descended/inspired from a xilinx design
<rqou>
ice40 looks more altera-like
<daveshah>
Yes, the Lattice/Xilinx connection goes back to ATT/Lucent
<daveshah>
Who istr made some Xilinx compatible devices
<daveshah>
Then eventually became part of Lattice through acquisitions and thus their fpga division
<daveshah>
They also shared an eda backend of many years as both used NeoCAD
<daveshah>
Until Xilinx abandoned NeoCAD and rewrote Vivado
<daveshah>
Lattice meanwhile are too sentimental/poor to fully bin NeoCAD so instead wrapped it in more crud and made Radiant
<whitequark>
lol
<daveshah>
FPGA archeology is fun
<daveshah>
Lattice also have the awful primitive library from the early 90s
<daveshah>
With really cryptic flip flop names
<daveshah>
FD1S3AX is a rising edge flip flop, no SR or CE, GSR for clear
<daveshah>
Trellis just abandons that and has one TRELLIS_FF primitive with parameters for the different mode
<daveshah>
Heh, this seems to be the official Lattice (ATT at this point) and Xilinx link