futarisIRCcloud has joined ##openfpga
tnt has quit [Ping timeout: 240 seconds]
tnt has joined ##openfpga
renze_ has quit [Ping timeout: 264 seconds]
renze has joined ##openfpga
finsternis has quit [Ping timeout: 246 seconds]
finsternis has joined ##openfpga
kuldeep has quit [Ping timeout: 252 seconds]
<qu1j0t3> yep
<qu1j0t3> every rose has its thorn
<qu1j0t3> every cowboy has a sad, sad saunnggg
kuldeep has joined ##openfpga
wbraun has quit [Quit: wbraun]
Ekho has quit [Ping timeout: 246 seconds]
Ekho has joined ##openfpga
inode has quit [Quit: ]
<whitequark> $ glasgow tool jtag-xc9500 -d 59604093 read-bit-usercode debug_card_expert.bit
<whitequark> I: glasgow.applet.jtag.xc9500: USERCODE=5f494350 (_ICP)
<whitequark> the entire applet is done
<whitequark> ok
<whitequark> program, verify, erase, read
<whitequark> no idea if it works lol
<whitequark> i mean
<whitequark> it verifies what was programmed
<whitequark> but i don't actually have any *bitstream*
<whitequark> ooooooops
<openfpga-github> [Glasgow] whitequark pushed 2 new commits to master: https://github.com/whitequark/Glasgow/compare/42511ec2e836...1c38cbe5d444
<openfpga-github> Glasgow/master 1c38cbe whitequark: applet.jtag.xc9500: new applet.
<openfpga-github> Glasgow/master eb7891d whitequark: applet.jtag: add run_test_idle() function.
<travis-ci> whitequark/Glasgow#134 (master - 1c38cbe : whitequark): The build has errored.
<sorear> original bitstream lost at this point?
<whitequark> nope
<whitequark> flashed it back
pie_ has quit [Ping timeout: 268 seconds]
<whitequark> thing is... none of these piece of shit thinkpads actually have the lpc bus routed anywhere
<whitequark> so i have nothing to test it on
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/a8a00084a349dde1798ac9a49bf050f3a52e40c4
<openfpga-github> Glasgow/master a8a0008 whitequark: applet.xc9500: doc clarification.
<travis-ci> whitequark/Glasgow#135 (master - a8a0008 : whitequark): The build has errored.
wbraun has joined ##openfpga
unixb0y has quit [Ping timeout: 246 seconds]
unixb0y has joined ##openfpga
<whitequark> azonenberg_mobil: ahahaha what the fuck
<whitequark> the 20 ms program delay from SVF isn't enough
<whitequark> it sometimes fails to program
<whitequark> or... hm
<whitequark> something else is wrong?..
<whitequark> azonenberg_mobil: btw i've confirmed the programming process is NOT self-timed
emeb has left ##openfpga [##openfpga]
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/77ecd82bc331578874be5ac3dbd07cd7bcefc82e
<openfpga-github> Glasgow/master 77ecd82 whitequark: applet.xc9500: make programming way faster than anyone would want....
<travis-ci> whitequark/Glasgow#136 (master - 77ecd82 : whitequark): The build has errored.
<openfpga-github> [Glasgow] whitequark force-pushed master from 77ecd82 to 8fecd8d: https://github.com/whitequark/Glasgow/commits/master
<openfpga-github> Glasgow/master 8fecd8d whitequark: applet.xc9500: make programming way faster than anyone would want....
<travis-ci> whitequark/Glasgow#137 (master - 8fecd8d : whitequark): The build has errored.
azonenberg_work has quit [Remote host closed the connection]
azonenberg_work has joined ##openfpga
<whitequark> ok
<whitequark> the fuck i was doing?..
<whitequark> why did i write this?....
<whitequark> no idea
<whitequark> azonenberg_mobil: can you make me a bitstream that uhhhhh
<whitequark> does `assign {pin_56, pin_58} = {pin_37 ~pin_37};` ?
<whitequark> i'll do an svf player i guess
<whitequark> wonder if either...
<whitequark> a) this device flashes like shit
<whitequark> b) i made an error somewhere
<whitequark> c) xilinx's programmer ignores flashing errors
<whitequark> because i get one or two page flash errors but everything flashes correctly
<whitequark> this could be like, a recycled device
<whitequark> easily
<sorear> what's a recycled device
<Bob_Dole> https://abopen.com/news/onchip-unveils-itsy-chipsy-ultra-low-cost-ic-fabrication-platform/ out of curiosity, how credible is onchip here with this? their twitter is pretty quiet.
<TD-Linux> I backed them on crowdsupply but they failed ;;
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Miyu has quit [Ping timeout: 268 seconds]
<emily> which might answer your question?
<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.
azonenberg_work has quit [Read error: Connection reset by peer]
azonenberg_work has joined ##openfpga
rohitksingh has joined ##openfpga
<whitequark> sorear: could be that your fabric is not reset properly
<whitequark> i.e. it's metastable
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined ##openfpga
<whitequark> azonenberg_mobil: 06:20 < azonenberg_work> whitequark: um, what package is this?
<whitequark> tq100
<whitequark> 08:08 < rqou> tl;dr of the xc9500xl flashing?
<whitequark> tl;dr of what?
<whitequark> it's d one
<azonenberg_work> whitequark: pm me the exact config you want and package and i'll get to it in the morning
<azonenberg_work> rebooted and lost the ise project (it was in /tmp)
<whitequark> ah ok
<azonenberg_work> so i forgot what pins went where
<whitequark> ok, time to poke prjtrellis
<whitequark> since i have a versa now
hackkitten has quit [Read error: Connection reset by peer]
hackkitten has joined ##openfpga
<whitequark> ok uhhhh
<whitequark> can someone send me lattice diamond
<whitequark> lattice is doing some stupid export control shit
<whitequark> actually fuck it, their loss
<daveshah> it's not their loss if you don't download diamond
<daveshah> they have to pay synopsys for synplify for every download
<whitequark> what.
<whitequark> i... guess... it's technically their gain then? lol
<daveshah> hehe
<whitequark> sure whatever
<whitequark> shouldn't they be happy about prjtrellis then?..
<daveshah> well, to be fair they aren't negative about it
<daveshah> and they did invite us to present icestorm at one of their workshops in europe
<whitequark> oh, they actually know?
<whitequark> niiiiice
<daveshah> yup
<whitequark> that's what i call a good vendor
<whitequark> daveshah: hm
<whitequark> nextpnr is one build tree per arch?
<whitequark> this seems... weird
<daveshah> everyone mentions that :P
<daveshah> it means we don't have the performance overhead of virtual functions or the n² build time cost of templates
<whitequark> hm
<whitequark> but you could use cmake to build a combinatorial set of libraries
<whitequark> fairly easily
<whitequark> i guess i can do that one day
<whitequark> -- Installing: /usr/local/share/trellis/database/.git
<whitequark> ... why
<daveshah> oops
<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
<whitequark> any blinky for versa-5g?
<daveshah> make sure you are on latest nextpnr (fix merged an hour ago), otherwise you might run into a problem with the global networks
<whitequark> yep
<whitequark> holy shit
<whitequark> that was FAST
Bike has joined ##openfpga
<daveshah> whitequark: heh, you worked out the /usr/local issue that was bugging me. I had assumed it was just how distros were set up
<daveshah> let me fix this
<whitequark> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
<whitequark> is what kitware wiki recommends
<whitequark> lemme check if thats actually sane
<whitequark> no it isn't
<whitequark> uhhh let me make it work on macos too
<daveshah> thanks
<whitequark> #42
<whitequark> daveshah: hm
<whitequark> Error: tdo check error at line 15
<whitequark> Error: MASK = 0xffffffff
<whitequark> Error: WANT = 0x81112043
<whitequark> Error: READ = 0x2224086
<daveshah> whitequark: have you set the jumpers to bypass ispclock?
<whitequark> oh.
<whitequark> wait
<daveshah> for now I don't consider that in the svf writer or openocd script
<whitequark> openocd cannot play SVFs to a specific tap?!
<whitequark> oh.
<whitequark> okay
<daveshah> it probably can, I just don't understand it well enough...
<whitequark> in glasgow it's a baseline capability...
<daveshah> J50 should be set 1-2 and 3-5
<whitequark> i mean it's not implemented yet because azonenberg's yet to send me an svf but i would not even push once without it
<whitequark> absolutely essential
<daveshah> ok svf in openocd does support -tap {tap}
<daveshah> #42 works, thanks!
<whitequark> daveshah: hmm
<whitequark> it programmed
<whitequark> and...... nothing changed
<whitequark> wrong boot straps?..
<sorear> what's the deal with lpf? why aren't io buffers instantiated directly from verilog like every other primitive?
<daveshah> whitequark: that's very odd
<daveshah> nothing on the display or LEDs?
<whitequark> it just did the same blinky thing as before
<whitequark> default lattice bitstream
<daveshah> hmm, I don't remember mine coming with that even
<daveshah> but mine was donated by q3k so I guess he had set it up
<daveshah> check that CFG0, CFG1 and CFG2 are all off (up)
<whitequark> yep
<whitequark> up now
<whitequark> Error: tdo check error at line 21740
<whitequark> Error: WANT = 0x000000200
<whitequark> Error: READ = 0x00b400000
<whitequark> Error: MASK = 0x000004200
<whitequark> now i get this
<daveshah> can you send the SVF file, so I can check on my board that the file is fine?
<whitequark> ok, i figured it out
<whitequark> svf -tap is broken somehow
<whitequark> Info : JTAG tap: ispclock.tap tap/device found: 0x00191043 (mfg: 0x021 (Lattice Semi.), part: 0x0191, ver: 0x0)
<whitequark> Info : JTAG tap: ecp5.tap tap/device found: 0x81112043 (mfg: 0x021 (Lattice Semi.), part: 0x1112, ver: 0x8)
<whitequark> Error: ecp5.tap: IR capture error; saw 0x47 not 0x1
<whitequark> hmmm
<daveshah> yeah, this is why I gave up and just used the bypass jumpers
<whitequark> let's see
<whitequark> wtf?
<whitequark> who set -irlen 2?
<daveshah> that was openocd's auto detect
<whitequark> well it's shit
<daveshah> tbh my understanding of jtag is pretty limited
<daveshah> this was my first time using anything other than vendor jtag tools really
<whitequark> should be -irlen 8
<whitequark> but that still doesn't work even though it scans correctly
<whitequark> interesting
<daveshah> yup, seeing that too myself
<whitequark> #43
rohitksingh has quit [Ping timeout: 250 seconds]
<whitequark> daveshah: hm
<whitequark> wondering if i need an irscan beforehand...
<whitequark> openocd's svf command is not exactly documented
<whitequark> wow
<whitequark> i altered the svf file and openocd... segfaulted
<whitequark> quality software.
<daveshah> yeah, openocd does seem pretty temperamental
<whitequark> nope, does not cooperate
<whitequark> jumpers it is.
<whitequark> wait
<whitequark> Error: tdo check error at line 21740
<whitequark> Error: WANT = 0x000000200
<whitequark> Error: READ = 0x00b400000
<whitequark> Error: MASK = 0x000004200
<whitequark> how is this an error?!
<daveshah> seems to make sense?
<daveshah> the 0x200 is missing
<whitequark> oh
<whitequark> ok sure
<whitequark> misread it
<sorear> is this a use of openocd that future-glasgow would be able to replace?
<whitequark> yes
<whitequark> current-glasgow even
<whitequark> but using glasgow with versa likely requires replacing some resistors (??)
<whitequark> Note: Resistors R38, R33, R32 and R36 need to be removed for programming with J3.
<sorear> let's say you want to use the ftdi chip and not do a lot of soldering work, but you don't want to use openocd
<whitequark> no
<whitequark> i thought about it
<whitequark> this is explicitly unsupported
<whitequark> i will not take it onto myself to validate correctness of ftdi designs
<whitequark> esp. given that ftdi is a buggy piece of shit
<daveshah> yup
<sorear> so that would be an example of something that's in-scope for jtaghal but out of scope for glasgow
<whitequark> correct
<daveshah> I would kind of be interested in seeing "embedded" glasgow for dev boards
<whitequark> daveshah: that was actually the original use case
<whitequark> drop-in replacement for ftdi
<whitequark> then... scope creep lol
<whitequark> i mean, it is called "glasgow" because ftdi hq is in glasgow
<whitequark> daveshah: anyway, i am thinking about a minimal module with just fx2 and fpga, likely non-bga
<whitequark> on a module with castellated pins
<sorear> what's the fpga needed for
<whitequark> that's where the actual glasgow runs
<whitequark> fx2 is just for usb comms
<daveshah> seems like the digilent module
<whitequark> oh?
<daveshah> which is like $50 for just an FT232H on a castellated board
<daveshah> with the digilent "secret key" in eeprom
<daveshah> glasgow would be a great replacement for that
<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
<whitequark> what
<daveshah> you do have to type yes, to be fair
<daveshah> but that is the default
<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)
<daveshah> cr1901_modern: there is a blinky here https://github.com/SymbiFlow/prjtrellis/blob/master/examples/tinyfpga_rev2/morse.v (if you have one of the newer type-C ones)
<daveshah> that still uses the older TRELLIS_IO style ports, I haven't done a LPF
<daveshah> but it's only two pins in that example anyway
<cr1901_modern> LPF?
<daveshah> the Diamond constraint file format that nextpnr also supports now
<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
<whitequark> whoa, multiple clock domains <3
<whitequark> i need that for glasgow for sure
<whitequark> revCD too
<whitequark> hella sweet
<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
<sorear> i mean you could do the abstractions better if you were using a less awful language than c++ templates to process them
<cr1901_modern> Please don't ruin the tweet :)
<sorear> someday someone is going to do a JIT for c++ templates, it shouldn't be inherently harder than native code compiling prolog
<sorear> might already have happened
GenTooMan has joined ##openfpga
<cr1901_modern> daveshah: prjtrellis built fine under msys2... still waiting on nextpnr and yosys
rohitksingh has joined ##openfpga
<cr1901_modern> daveshah: What path do you actually pass to -DTRELLIS_ROOT?
<cr1901_modern> Is it where I actually installed everything?
<daveshah> No, its the path to where you cloned prjtrellis
<cr1901_modern> Weird... why does it want that?
<daveshah> It's to do with accessing some Python stuff which isn't installed
Miyu has joined ##openfpga
<cr1901_modern> Does it by any chance assume that I didn't do an out-of-tree build of prjtrellis?
<cr1901_modern> (which I did)
<cr1901_modern> Yes. Yes it does
<cr1901_modern> daveshah: I suppose that's my fault for deviating from the insns: https://github.com/SymbiFlow/prjtrellis/pull/44
<cr1901_modern> Oh damnit, you require that "signed off by" stuff
<cr1901_modern> daveshah: May want to close my PR and add the change manually; I just edited directly from Github editor to make things quick
<daveshah> cr1901_modern: I don't require it
<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
rohitksingh has quit [Ping timeout: 252 seconds]
<cr1901_modern> daveshah: Okay, nextpnr-ecp5 builds successfully on Windoze after a few minor changes: https://github.com/cr1901/nextpnr/tree/win-fix Will make a PR in a bit
<daveshah> thanks!
* cr1901_modern takes a snooze for now
jevinski_ has quit [Ping timeout: 252 seconds]
jevinskie has joined ##openfpga
<whitequark> azonenberg_work: does svf have a spec?
<azonenberg_work> i think so but i dont know where to find it
<azonenberg_work> feels like probably a jedec standard
<whitequark> ok
<rqou> azonenberg_work: https://twitter.com/azonenberg/status/1058772234867593216?s=19 <-- i could have told you that
<azonenberg_work> rqou: you weren't around :p
<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
carl0s has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 252 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 268 seconds]
<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
OhGodAGuardian has quit [Remote host closed the connection]
<marshallh> altera was naming fpgas after the dragons from How to Train Your Dragon
<marshallh> max10 is NIGHTFURY
<marshallh> before that, they used mythology
<daveshah> Lattice have codenames too
<daveshah> IIRC Ultra was ThunderBolt and UltraPlus ThunderPlus
<daveshah> Not sure if ecp5 has a codename
<daveshah> Seems the ecp5s codename is Sapphire
<whitequark> ThunderBolt
<daveshah> yep lol
<daveshah> Like the least likely fpga in the world for it too