Bob_Dole has quit [Read error: Connection reset by peer]
lopsided98_ is now known as lopsided98
Bike has quit [Quit: Lost terminal]
gsi__ is now known as gsi_
Bob_Dole has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 246 seconds]
dj_pi has quit [Ping timeout: 246 seconds]
<Sprite_tm>
Has anyone tried to feed the synthesized verilog output from Yosys into Verilator?
<Sprite_tm>
I'm trying now and it seems to work... except that Yosys wires up a bus to the module by naming the individual wires and Verilator does not like this.
<Sprite_tm>
So you'll have a bunch of .\DI[0] (\cpu.mem_addr[13] ), inputs instead of .DI ({cpu.mem_addr[13], ...}),
rohitksingh has joined ##openfpga
<Sprite_tm>
Ah, fugeddabout it, seemingly there's no DP16KD sim model available yet.
oeuf has quit [Ping timeout: 258 seconds]
emeb_mac has quit [Ping timeout: 255 seconds]
Jybz has joined ##openfpga
OmniMancer has joined ##openfpga
GuzTech has joined ##openfpga
flea86 has joined ##openfpga
Bob_Dole has quit [Ping timeout: 276 seconds]
rohitksingh has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
oeuf has joined ##openfpga
_whitelogger has joined ##openfpga
s_frit has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Asu has quit [Read error: Connection reset by peer]
Asu` has joined ##openfpga
ZombieChicken has quit [Ping timeout: 256 seconds]
ZombieChicken has joined ##openfpga
Asu` has quit [Ping timeout: 244 seconds]
Asu` has joined ##openfpga
Asu` has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
<Sprite_tm>
Another question: is it a known issue that on the ECP5, block rams that aren't DP16KD aren't initialized properly? They seem to contain 0 here.
<Sprite_tm>
From what I can tell, the synthesized memory contains all zeroes.
<Sprite_tm>
I tried generating a blif file, and from what my unexperienced eyes could see, there's something there wrt initialization, but I'm not sure.
<Sprite_tm>
If it's not a known issue (and you don't see any stupid mistakes in my verilog) I can see if I can create a testcase.
<daveshah>
I don't see any issues, a test case would be useful but I probably won't be able to look at until Friday
<daveshah>
the posted Verilog doesn't describe a block RAM btw, I presume rdata is being registered somewhere?
<Sprite_tm>
Ah, sorry, it's not a block RAM I guess... it's a cache flag memory so rdata is used directly.
Asu has quit [Quit: Konversation terminated!]
Asu has joined ##openfpga
Bob_Dole has joined ##openfpga
emeb has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
GuzTech has quit [Remote host closed the connection]
lexano has quit [Ping timeout: 245 seconds]
lexano has joined ##openfpga
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
azonenberg_work has quit [Ping timeout: 276 seconds]
<tnt>
Just made myself a couple of 'bitsy' board (from esden's design) and as expected usb works just fine :) ((pretty much one year after I originally found out about them from the logs :p)
<esden>
tnt: ok I guess I need to order some PCBs ;)
genii has joined ##openfpga
azonenberg_work has joined ##openfpga
* emeb
is a big fan of STM32
mossmann has quit [Ping timeout: 264 seconds]
mossmann has joined ##openfpga
Thorn has quit [Ping timeout: 258 seconds]
azonenberg_work1 has joined ##openfpga
azonenberg_work has quit [Ping timeout: 244 seconds]
Thorn has joined ##openfpga
azonenberg_work1 has quit [Ping timeout: 250 seconds]
azonenberg_work has joined ##openfpga
m_w has joined ##openfpga
msgctl has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
<xobs>
I think I know the answer but -- can the ICE40 do dynamically configurable IO pullups? I suspect not, because PULLUP is a defparam...
<daveshah>
In general it can't
<daveshah>
The only exception are the two I3C IO pins on the UltraPlus
<daveshah>
You'd obviously have to have a lot of luck if it's an existing board for this to work
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
rohitksingh has quit [Ping timeout: 258 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<xobs>
That's a good point. And I thought I'd make the I3C pins be the USB pads, which isn't so helpful here. Nice hack daveshah .
<daveshah>
Perhaps you could simulate a pullup by pulsing output enable (with output value 1'b1) with low duty cycle and high frequency
* daveshah
hides
<SolraBizna>
:C
<SolraBizna>
why am I suddenly sure that some Lattice devboard or softcore actually does that
<xobs>
daveshah: that's what I was contemplating doing. The goal is to detect a short to enter a recovery mode. It might be possible to send a known pattern out one pin and pick it up on the other. Of course, any flux or coupling is going to make that a bad idea.
<azonenberg_work>
There's another option
<azonenberg_work>
Have two pads tied together by a resistor
<azonenberg_work>
for each line
<azonenberg_work>
Use the other pin as a dynamic pullup
<azonenberg_work>
drive 0, 1, or Z to pull down, up, or float
<xobs>
That's how the USB FS pullup works.
<xobs>
Well, there's still time to come up with solutions.
<azonenberg_work>
You can do all kinds of dirty tricks with multiple gpios and a few resistors
<azonenberg_work>
i know somebody who is doing MIPI D-PHY that way
<adamgreig>
and 100mbps ethernet eh
<azonenberg_work>
and yes, ethernet :p
<SolraBizna>
that's actually a clever solution
<SolraBizna>
wish I'd thought of it
<azonenberg_work>
xobs: on the topic of usb pulls, did you see the demo video i posted of usb decode in glscopeclient?
<xobs>
azonenberg_work: I didn't. That sounds really useful. Where is it?
<azonenberg_work>
This is a WIP and there's some backend/driver work needed to support non-lecroy scopes and it hasnt been tested on anything but ubuntu/debian linux
<azonenberg_work>
But it should eventually be cross platform and support any scope you can think of as long as it provides a SCPI backend and/or some kind of SDK/API
cr1901_modern2 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 245 seconds]
cr1901_modern1 has quit [Ping timeout: 244 seconds]
<azonenberg_work>
xobs: ^
<azonenberg_work>
on the same channel i have a demo of it doing some high speed serial decode too
<SolraBizna>
I'm confused by something in the iCE40 LP/HX family data sheet... trying to figure out the max current I can safely ram through a sysIO pin
<xobs>
azonenberg_work: that looks super handy. I'd love to be able to get rid of this USB Beagle. It's really really handy, and it works on Windows, but this poor PCB has been through a lot.
<xobs>
Like, the GND pin isn't connected anymore on the passthru line. So I have a hacked cable that bypasses GND.
<azonenberg_work>
LOL
<azonenberg_work>
so, the issue with this technique is that you need a trigger event
<xobs>
And the Beagle doesn't do low-level analysis. Which is a problem when you're writing the PHY.
<SolraBizna>
even if I'm interpreting I_OL and I_OH correctly (current while outputting low, current while outputting high)... there are two rows, and I'm not seeing an explanation for what the difference is
<azonenberg_work>
Because there is dead time between scope triggers where you will miss packets
<daveshah>
SolraBizna: it isn't defined any more
<azonenberg_work>
But for low level PHY debug this is perfect, i explicitly expose all layers of the protocol for this reason
<SolraBizna>
either the maximum is 8mA (acceptable for what I'm doing) or it's 0.1mA (way too low for what I'm doing)
<daveshah>
Older iCE40 datasheets used to specify 20mA abs max
<azonenberg_work>
in fact i would LOVE for you to do phy development on it, because you will probably emit all kinds of invalid states
<azonenberg_work>
and we can stress test my decoder on it
<daveshah>
8mA is a nominal current for a given output voltage
<daveshah>
In fact it will do a lot more if shorted
<azonenberg_work>
xobs: can you toggle a GPIO briefly before sending the packet of interest?
<azonenberg_work>
and what oscilloscope(s) do you have?
<SolraBizna>
so if I have a 400mΩ resistor right in front of the pin, I'm pretty definitely totally fine?
<SolraBizna>
er, Ω, not mΩ
<xobs>
azonenberg_work: I can! And that's what I might end up doing.
<daveshah>
SolraBizna: yes that will be fine
<SolraBizna>
yay
<azonenberg_work>
xobs: note also that the usb decoder has only been tested in FS mode
<xobs>
azonenberg_work: For oscilloscopes, I have a Tek in the office, and I have an MSO-28 on the road, with... I think it's an MSO9201 or MSO9212 available too.
<azonenberg_work>
I know for a fact that HS stuff is missing, and i don't have any LS stuff to test against
<azonenberg_work>
xobs: Are you interested in doing development of a glscopeclient driver?
<azonenberg_work>
agilent and tek stuff is not currently supported but i have open tickets for both
<azonenberg_work>
the holdup right now is lack of hardware to test on
<azonenberg_work>
i run a 100% lecroy shop if you don't count the dead rigol i have no interest in fixing
<xobs>
azonenberg_work: possibly. The only wrinkle is that I tend to use Windows, which is why the Beagle is handy.
<azonenberg_work>
xobs: This tool is intended to be cross platform
<azonenberg_work>
I've only tested on linux but there are no deliberate linux-isms in the codebase
<azonenberg_work>
and GTK and OpenGL are portable
<azonenberg_work>
Would probably be easiest if you used cygwin/mingw to compile it, but somebody needs to test :p
<azonenberg_work>
i have literally not even attempted to compile on windows
<cr1901_modern2>
Probably shouldn't be that bad
<azonenberg_work>
Yeah
<cr1901_modern2>
but _I'm_ not delving down that rabbit hole tonight
<azonenberg_work>
xobs: also, my tool can handsle multiple scopes simultaneously
<cr1901_modern2>
in case I eat my words
<azonenberg_work>
So you can set up two scopes with cross-trigger and treat them as one 8-channel instrument
<azonenberg_work>
even if they have different timebases etc
<xobs>
Super fancy.
<azonenberg_work>
Not all math functions handle non-uniform sample rates on inputs, but i'm working on fixing that
<azonenberg_work>
Development chatter is currently in #scopeclient
<azonenberg_work>
#scopehal *
<azonenberg_work>
(cant brain today)
Dolu1990 has joined ##openfpga
<sorear>
why aren't triggers retroactive?
<azonenberg_work>
sorear: They can be
<azonenberg_work>
Right now libscopehal doesnt have an API for setting the trigger point within the waveform
<azonenberg_work>
but you can use the trigger settings on the scope front panel to move the trigger anywhere from the start to end of the waveform and i think even off the end of it
<azonenberg_work>
basically what happens is the scope captures into ram constantly when the trigger is armed, then stops shortly after the trigger occurs
<azonenberg_work>
you can control that offset freely
<sorear>
so the "toggle a GPIO briefly before sending a packet" is a temporary bootstrapping thing
<azonenberg_work>
Well, what i meant is
<azonenberg_work>
you need to signal WHICH packet you're interested in
<azonenberg_work>
Because between triggers, during waveform download, the scope will not be recording data
<sorear>
idle poll rate is what, 1000/s? scope can't handle that rate?
<azonenberg_work>
not even close
<azonenberg_work>
not over usb/lan at least
<azonenberg_work>
modern scopes are not designed for this, sadly (mine will be)
<azonenberg_work>
In the demo, i triggered on every packet in sequence mode
<azonenberg_work>
So you got every single packet, until the scope ran out of ram
<azonenberg_work>
then there was a ~600ms lag while i download the waveform and you miss 100% of traffic
<azonenberg_work>
then it repeats
<azonenberg_work>
the video looks smooth because i download 500 waveforms in bulk then pull 25 at a time, run protocol decodes , and render the single most recent
<azonenberg_work>
But if you look at sequence numbers in the pcap scroll you'll notice occasional jumps
<azonenberg_work>
You can get 100% of the data for a short time, but you can't stream nonstop
azonenberg_work has quit [Remote host closed the connection]
azonenberg_work has joined ##openfpga
<azonenberg_work>
(back, client crashed when switching channels somehow)
<azonenberg_work>
Anyway, when i build my own scope it will be purpose-built for streaming
<azonenberg_work>
But most COTS stuff simply lacks the optimization to stream kWFM/s real time
<xobs>
The Beagle has some sort of FPGA on it. Maybe a Spartan3? I haven't compared pinouts to figure out what it is. The chip is labeled "Total Phase".
<azonenberg_work>
So either an asic or a rebranded fpga
<azonenberg_work>
If you dump the flash chip i can id the fpga from the bitstream if it's a xilinx part
<azonenberg_work>
(That's how i found out there was an... xcku085 i think... in my waverunner)
<sorear>
how common is rebranding?
<azonenberg_work>
Dont know, i have not seen a rebranded fpga yet
<daveshah>
Pretty sure I've heard of them being available if you order enough
<sorear>
given how much you take apart that seems like strong evidence
<azonenberg_work>
let me rephrase
<azonenberg_work>
i have never confirmed a non-fpga-labeled part was truly an fpga
<azonenberg_work>
but i often dont put a ton of effort into IDing chips from random scrap boards