azonenberg_work has quit [Ping timeout: 246 seconds]
_whitelogger has joined ##openfpga
futarisIRCcloud has joined ##openfpga
<futarisIRCcloud> sorear: What were you saying about antmicro's linux port a couple of months ago?
dj_pi has joined ##openfpga
azonenberg_work has joined ##openfpga
unixb0y has quit [Ping timeout: 245 seconds]
unixb0y has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
<bubble_buster> lmao 624 bit RISC-V instructions? http://svn.clifford.at/handicraft/2019/rvlonginsn/README
<bubble_buster> is this satire?
<whitequark> nope
<fseidel> we're getting dangerously close to VAX territory here
<whitequark> i think variable length instructions for RISC are a superb idea
<whitequark> i do that in my ISA
<whitequark> it makes it waaaay nicer
<fseidel> oh, I'm not saying variable length is a bad idea
<fseidel> fixed width bit SPARC in the ass REAL hard (take a look at the way they handled vector extensions on VIIIfx, yuk)
<fseidel> but 624 bits seems... extreme
<sorear> i'm confused
<sorear> there are two layers here: one which breaks a bit stream into "instructions", and one which decodes the individual instructions
<sorear> why do you want to impose an arbitrary upper limit on length decoding?
<sorear> length decoding needs to be as simple as possible for superscalar decode to work well
<fseidel> I feel like imposing an upper limit makes it faster to decode though
<sorear> (one of the things x86 *does* get wrong is that length decoding needs hundreds of cases, because only some instructions have modr/m bytes or immediates)
<sorear> if a specific real chip doesn't implement any instructions longer than 64 bits, it only needs the 16b/32b/48b/64b cases
<futarisIRCcloud> whitequark: Did the TPS65983 / Thunderbolt stuff get anywhere? https://freenode.irclog.whitequark.org/~h~openfpga/2018-10-28
<fseidel> how would you suggest doing decode in a non-prefix-byte-style way that doesn't impose an upper limit?
dj_pi has quit [Ping timeout: 245 seconds]
<sorear> well there's an upper limit, but it's large enough that no silicon vendor has to care about it
<sorear> except some people are for some reason bothered ???
<whitequark> futarisIRCcloud: not exactly
<whitequark> i never figured out what was wrong with that card
<whitequark> rqou sent me a TBT3 one (thanks rqou!)
<whitequark> and it... just worked
<whitequark> i'm going to get an USB C analyzer and compare the exchanges
<whitequark> but i can't do it right now because tapping USB C control lines on a live card i really don't want to damage is... hard
<futarisIRCcloud> Which TBT3 card?
<futarisIRCcloud> https://www.microsemi.com/product-directory/dev-kits-solutions/3864-polarfire-kits - Is the PolarFire Future Avalanche the only cheap MicroSemi PolarFire board?
dj_pi has joined ##openfpga
<futarisIRCcloud> Looks like AntMicro were using it last year (with LiteX) ...
<sorear> futarisIRCcloud: I don't follow the question re. Antmicro and Dolu's work on riscv32 linux support
<sorear> there is currently a vexriscv fork with a software-managed TLB, and a hacked bbl+linux which works on it; daveshah did a demo
<sorear> it would be possible to move all of the hacks to BBL so that Linux sees a standard S-mode environment, but AFAIK their plan is to modify vexriscv (at unspecified cost) to be more similar to Rocket, with a h/w page table walk
gsi__ has joined ##openfpga
dj_pi has quit [Ping timeout: 245 seconds]
<futarisIRCcloud> sorear: I'm trying to get it running on Arty A7.
<sorear> mm, maybe ask daveshah, who got it running on a 45k versa
<sorear> i have some information but I haven't really looked closely at that issue in weeks
<whitequark> futarisIRCcloud: the sonnet tbt3 upgrade card
gsi_ has quit [Ping timeout: 250 seconds]
Bike has quit [Quit: Lost terminal]
togemet2 has joined ##openfpga
wpwrak has quit [Ping timeout: 255 seconds]
wpwrak has joined ##openfpga
rohitksingh_work has joined ##openfpga
jevinskie has joined ##openfpga
emeb_mac has quit [Ping timeout: 255 seconds]
sgstair has quit [Read error: Connection reset by peer]
sgstair has joined ##openfpga
ZombieChicken has quit [Ping timeout: 256 seconds]
ZombieChicken has joined ##openfpga
gnufan_home has quit [Quit: Leaving.]
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 276 seconds]
Asu has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
<keesj> how does on validate a test bench without looking at the waveforms
<keesj> is there an assert or similar?
Flux42 has quit [Quit: BRB]
Flux42 has joined ##openfpga
m_t has joined ##openfpga
scrts has quit [Ping timeout: 258 seconds]
Laksen has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 258 seconds]
m_t has quit [Read error: Connection reset by peer]
scrts has joined ##openfpga
zino has quit [Ping timeout: 240 seconds]
ZombieChicken has quit [Ping timeout: 256 seconds]
zino has joined ##openfpga
zino has quit [Client Quit]
zino has joined ##openfpga
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
Laksen has quit [Ping timeout: 250 seconds]
genii has joined ##openfpga
carl0s has joined ##openfpga
zino has quit [Ping timeout: 258 seconds]
rohitksingh has joined ##openfpga
zino has joined ##openfpga
togemet2 has quit [Read error: Connection reset by peer]
azonenberg_work has quit [Ping timeout: 276 seconds]
<felix_> whitequark: found this on compatibility of tb3->tb2 adapters https://help.uaudio.com/hc/en-us/articles/215733823-Apollo-Twin-Thunderbolt-Windows-Compatibility
<whitequark> that's a completely different adapter
<whitequark> i'm 95% sure the problem is somewhere in USB PD negotiation
<whitequark> i just can't figure out where
<felix_> didn't you try the apple tb3->tb2 adapter?
<felix_> so there are two other adapters that seem to work. but yeah, you solved the problem differently
<whitequark> felix_: those tb3->tb2 adapters are incredibly expensive
<whitequark> and there's no reason they shouldn't work
<felix_> yeah
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 246 seconds]
rohitksingh has quit [Ping timeout: 258 seconds]
emeb has joined ##openfpga
X-Scale has quit [Ping timeout: 246 seconds]
SpaceCoaster has quit [Ping timeout: 268 seconds]
SpaceCoaster has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
X-Scale has joined ##openfpga
Richard_Simmons has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
<hackerfoo> Is anyone here getting one of these? https://www.crowdsupply.com/rhs-research/nitefury
rohitksingh has quit [Ping timeout: 250 seconds]
azonenberg_work has joined ##openfpga
_whitelogger has joined ##openfpga
Bob_Dole has joined ##openfpga
Laksen has joined ##openfpga
<keesj> it that used in open source software (system verilog) ?
rohitksingh has joined ##openfpga
<daveshah> Verilator supports them, and Yosys supports them for formal verification
<daveshah> not sure about Icarus
<keesj> Perhaps I am asking the wrong question. I want to write a test bench that (fully) tests my module
<SolraBizna> iverilog does not have assume or assert, last I checked
<keesj> how do I do that using open source tools?
<SolraBizna> you can make a testbench module that uses `initial` blocks and delay statements to apply certain signals to the module you're testing
<SolraBizna> then there are various non-synthesizable things (like `$display` and `$finish` and stuff for file I/O) you can use to get input to and output from such a testbench
ZombieChicken has joined ##openfpga
<keesj> I created a very simple module for an ultra sonic distance sensor https://github.com/keesj/tinyfpga_examples/blob/ultrasensor/ultra_sonic_sensor/sr04.v
<keesj> I would like to validate some signals (e.g. assert like) but I also heard ZipCPU and others about formal validation. I don't really know where to start/how to start on this
<ZipCPU> keesj: Have you looked at my tutorial at all?
<keesj> (any comments on code are also welcome)
<keesj> ZipCPU: I have read a few articles but no . did not follow any tutorial yet
* ZipCPU reviews keesj's code
<ZipCPU> Here's my thought: You want a property that following a reset, the design goes into a reset state for a minimum number of clocks before being ready (lest you get a reset, request, and response from prior to the reset)
<ZipCPU> You'd also want a property (or set of properties) describing a sequence from request, through transmit, through waiting, through receive, through idle (or new request) again
<ZipCPU> You might find that a poor man's sequence works really well for this purpose. See http://zipcpu.com/formal/2019/02/21/txuart.html
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 276 seconds]
<keesj> so .. a reset state.. I will read the article (and find the tutorial :P ) thanks.
Richard_Simmons has quit [Read error: Connection reset by peer]
<elms> keesj: There are many ways to shave a cat. I am far from an expert and also want to explore Formal methods more, but I'll mention cocotb and UVM in general *takes cover* Again not advocating any specific approach, but mentioning for context
<elms> It's slightly more humane than the original idiom and I felt like it's more of a cat problem then a yak (ie it has claws and is fickle)
Bob_Dole has joined ##openfpga
<elms> Does anyone have thoughts/pointers about determining internal delays for FPGA blocks? For example trying to reading and writing data at the same address to a RAM at almost the same time. RCLK and WCLK are not quite in sync. I recognize this should be avoided in real designs.
<elms> I was planing to look at vendor tools and see if there is any visibility. Wondering if there is a way to fuzz values out.
<elms> daveshah: thanks will look at that
emeb_mac has joined ##openfpga
<sorear> if you find out, let me know too
Adluc has quit [Ping timeout: 252 seconds]
Adluc has joined ##openfpga
<azonenberg_work> elms: you mean for cross clock stuff?
<azonenberg_work> or the same clock domain?
<azonenberg_work> elms: TMSC specifies write-to-read delays for their dual port sram IP, but it looks like xilinx's ram doesn't have any such spec
<azonenberg_work> normally this isn't an issue because in a dual clock fifo, you have a 3-stage synchronizer between the write and read clock domains to keep track of the pointers
<azonenberg_work> this adds a few clocks of latency so the data has more than stabilized by the time you need to read it
<azonenberg_work> as a general rule i would wait at least one cycle of the faster clock after the write before reading
<azonenberg_work> because that gives you the same effective setup time as if you had written then read back in the same domain
rohitksingh has quit [Ping timeout: 245 seconds]
Jybz has joined ##openfpga
<elms> azonenberg_work: I'm looking at it for modeling it accurately for FPGAs (even for poor designs). I haven't been able to find any specs and hence why I was asking.
<azonenberg_work> Yeah i dont see any specs
<azonenberg_work> you could try measuring by writing in one clock domain and reading in another and sweeping pll phase until data gets corrupted
<azonenberg_work> but i dont know how useful that will be, because that only gives you data for one particular die
<elms> In general i think the lut+ff type blocks are well documented by vendors and all other blocks have a lot of missing details.
<azonenberg_work> you'd need to test hundreds or thousands at a range of voltages and tempes to be confident you had a reliable spread for fast/slow PTV corners
<azonenberg_work> Or you could test a few and extrapolate to get a conservative number
<elms> azonenberg_work: I wonder if I can simulate a design and get some insight into any non published model they use
<azonenberg_work> say double the worst case deviation you had seen or something
<azonenberg_work> cant hurt to try but my gut says that isnt something their sim models will detect well
<sorear> some, but not all, vendors are also silent on what happens if you do a simultaneous read and write from two ports sharing a clock
<azonenberg_work> oh thats cool
<azonenberg_work> UG473 page 20
<azonenberg_work> xilinx specifies a 3000 ps collision interval
<azonenberg_work> it just isnt in the datasheet
<azonenberg_work> re simultaneous read and write with same OR different clocks, xilinx specifies clearly
<azonenberg_work> i wish everyone did
<azonenberg_work> for the most part though, dual port ram is normally 8T cells
<azonenberg_work> So read-during-write will give nondeterministic read data and the write will execute normally
<azonenberg_work> colliding writes will give nondeterministic data
<azonenberg_work> and colliding reads are harmless
<sorear> why wouldn't read-during-write just bypass the cells and have the write bit lines directly drive the read bit lines?
<sorear> (I have a really weak understanding of sub-cycle event timing in SRAMs, which is probably the answer here)
<sorear> (if you have any vaguely modern SRAM spec sheets to share with timing, I'd like to see)
<azonenberg_work> The p1/p2 bitlines aare long and have parasitics
<azonenberg_work> and sram write basically bus fights the bit cell and eventually wins
<azonenberg_work> so midway through the state is unpredictable/metastable since you have 2 drivers on a shared bus
<whitequark> oooh
<whitequark> i have obtained mipi csi and d-phy specs
<sorear> read-during-write adds load on the bit cell's side of the pass transistor, but I guess they budget for that
<azonenberg_work> Yeah
<azonenberg_work> the bigger issue is just that you have both the bitline and the inverter loop driving the other bitline
<azonenberg_work> and the result isnt guaranteed to be consistent
<daveshah> whitequark: which version?
<whitequark> dphy 1.2, csi 2
<daveshah> You mean CSI-2 or CSI-2 2.0 (yes it's stupid)
<daveshah> I've only ever found a draft of CSI-2 1.0
<elms> azonenberg_work: thanks fot the xilinx UG reference
<whitequark> daveshah: what the fuck
Jybz has quit [Quit: Konversation terminated!]
<whitequark> daveshah: CSI-2 1.01
<daveshah> Nice, are you able to share?
<whitequark> yea
<whitequark> i'll upload them
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 276 seconds]
gnufan_home has joined ##openfpga
Laksen has quit [Quit: Leaving]
ZombieChicken has quit [Ping timeout: 256 seconds]
ZombieChicken has joined ##openfpga
carl0s has quit [Quit: Page closed]
Asu has quit [Remote host closed the connection]
Bob_Dole has joined ##openfpga
Richard_Simmons has quit [Ping timeout: 276 seconds]
Bike has joined ##openfpga
<mithro> daveshah: Have you given a presentation / talk / anything else about the self-hosted nextpnr on the ECP5?
<azonenberg_work> self hosted??
<azonenberg_work> like, softcore risc-v with linux running on an ecp5?
<sorear> yes
<sorear> i don't think the full flow for the linux soc was run on the ecp5, but nextpnr-ecp5 did work in some case
<sorear> the 45k, even (not the 85k)
<sorear> this is riscv32 and still requires a lot of software handholding (all distro work has focused on 64-bit, only the 64-bit libc is upstream, and the linux-supporting vexriscv is still a bit immature and requires a patched linux)
genii has quit [Remote host closed the connection]
gnufan_home has quit [Quit: Leaving.]
azonenberg_work has quit [Ping timeout: 246 seconds]
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 276 seconds]