<awordnot>
and do you have an easy way to scope the chip select pin?
tpb has quit [Remote host closed the connection]
<tpearson-mobile>
I'd have to set that all up -- asking here before I start debugging something that I had thought was a plug+play (plug and pray?) peripheral :)
<tpearson-mobile>
pins are definitely set up correctly though
tpb has joined #litex
<awordnot>
maybe someone else can offer some more insight, but to me everything looks fine
<tpearson-mobile>
OK. If it seems good, I'll start digging into it then
<tpearson-mobile>
awordnot: one thing I do find very irritating though about Migen (besides the verbosity (seriously, self.comb(foo.eq(bar)) vs foo = bar??) is I can't do my normal "assign debug_out = some_output_pad"
<tpearson-mobile>
so then you end up wasting a bunch of time trying to get physical probes onto certain signals where the FPGA is normally perfectly able to probe its own internal logic.
<tpearson-mobile>
feels a bit like going back to the stone age :)
<tpearson-mobile>
if I'm missing some way to do that, I'm all ears
<awordnot>
you can access the pads' signals using e.x. platform.request("spiflash4x").miso and add normal comb domain assignments to/from it
<tpearson-mobile>
will that work though if it's driven by another module? when I tried it, it was causing problems, and digging into it the signals were being set to input
<tpearson-mobile>
always possible I was doing something slightly wrong, of course, so if it's supposed to work I'll give it another try
<awordnot>
it should work regardless, but if it's being driven by another module you can just access that module's signal directly
<tpearson-mobile>
well, in this case, it's being driven by the SPI module, so I'd have to dig into that in some other repo -- not the easiest thing to do
<tpearson-mobile>
I'll give direct attach another try
<awordnot>
yeah, i've done the direct attach method a couple of times and it worked fine
<tpearson-mobile>
I will say I'm surprised at the SPI module handling of whatever is going wrong -- spitting back the lowest address byte in the data stream is not what I expected, 0xff or 0x00 was expected in that case....
<tpearson-mobile>
awordnot: Ah, here's why it doesn't work: "ERROR: Pin B of TRELLIS_IO 'TRELLIS_IO_21' connected to more than a single top level IO.ERROR: Packing design failed"
<tpearson-mobile>
normally I'd tap into the input line to work around that (since input is always working even if the pin is in output mode) but in this case, I'm not sure if there's an easy way to tap into all the abstractions to get at the signal I want
<felix_>
i wouldn't call the two flash chips nearly identical. 128MBit is 3 byte addressing; more than that needs 4 byte addressing or some other mode where the 4th byte is set via a separate command. might be part of the issue
<tpearson-mobile>
felix_: Oh, no 4 byte addressing on that controller?
<tpearson-mobile>
hrm
<tpearson-mobile>
yeah, that would mean different command sets....
<tpearson-mobile>
still, it should be failing in a bit of a different manner than what I'm seeing if that was the only issue
<felix_>
good question; never used it with spi flashes > 16MByte
<felix_>
yeah
<tpearson-mobile>
well, I'm going to see if we at least get CS# assert or not
<tpearson-mobile>
if so, it can be modified of course for 4BA, it's not *that* difficult
<tpearson-mobile>
I suspect we're dealing with an independent issue though at the moment
<tpearson-mobile>
I guess I kind of assumed it would have a 4BA option given some of the other extras on it like dummy cycle / QSPI support
<tpearson-mobile>
Interestingly there is a "addr_width" variable, hardcoded to 24
<tpearson-mobile>
I'll probably end up un-hardcoding that and submitting a PR
<tpearson-mobile>
it's strange because so much of the code is autogenerated / dynamic, having that hardcode is almost out of place...
<tpearson-mobile>
Huh. Re-synthesizing the design fixed the pattern weirdness
<tpearson-mobile>
I'm not even going to bother tracking that down, but yes, 4BA is something I have to add
<tpearson-mobile>
considering it's past dinner though that's waiting for another day :)
<tpearson-mobile>
thanks all!
tpearson-mobile has quit [Remote host closed the connection]
Skip has quit [Remote host closed the connection]
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #litex
futarisIRCcloud has joined #litex
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 246 seconds]
peepsalot has quit [Ping timeout: 246 seconds]
peepsalot has joined #litex
st-gourichon-fid has joined #litex
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 258 seconds]
kgugala_ has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 246 seconds]
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
Dolu has joined #litex
kgugala_ has joined #litex
kgugala__ has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has quit [Ping timeout: 258 seconds]
kgugala has joined #litex
kgugala__ has quit [Ping timeout: 246 seconds]
<futarisIRCcloud>
dkozel: When are you doing gr-verilog on bigbluebutton?
palmer has quit [Ping timeout: 256 seconds]
palmer has joined #litex
rlif has joined #litex
rlif has quit [Remote host closed the connection]
benh has quit [Ping timeout: 256 seconds]
benh has joined #litex
<dkozel>
futarisIRCcloud: Not sure. Been tangled in mentoring a lot of students who are all starting their summer FOSS projects this week
<dkozel>
also miek has published a proof of concept cxxrtl GNU Radio module which doubles my desire to get that functionality in before pointing more people at gr-verilog
<dkozel>
oh, hi miek :P Didn't realize you were in here
<dkozel>
Also been debugging GNU Radio Anaconda issues. Apparently lots of the FOSS FPGA toolchains are going to end up packaged according to mithro
<dkozel>
It'd also be great to have gr-verilog packaged there with all it's dependencies, it'd make it accessible outside of Linux
<miek>
hi :)
<dkozel>
I'm so pleased you got that working!
<keesj>
hmm gr-verilog? running on the plutoSDR?
<dkozel>
keesj: Just on a host. It's for including HDL in a GNU Radio flowgraph, running in a simulation backend (Verilator now, cxxrtl soon)
<dkozel>
But as a bridge to gr-litex, being able to build accelerator gatewares from a flowgraph (partially working)
<tnt>
Does cxxrtl (or verilator) work with the Xilinx simulation models ? (for DSP / BRAM / ...)
<dkozel>
I have no idea. I've never used a Xilinx model for anything
<tnt>
No synthesis tool can infer complex DSP function they can do, so if you want to actually use the fpga to its potential you don't really have a choice.
<keesj>
verilator not not even the ice40 pll
<keesj>
you will need to implement a simlator for the testing part (I think)
<dkozel>
I don't really care about using the FPGA to it's potential at this point. Getting even a basic implementation together has a lot of value in teaching situations.
<dkozel>
Also I think this is a stepping stone. The tooling is improving and even without the Xilinx models (which it looks like Verilator at least partially can handle) I'm guessing (and it is a guess) that there's useful DSP that can be written
<dkozel>
even if it turns out to be impractical, this is already a good learning experience for me. I didn't have anything I wanted to do after blinking an LED :)
<tpb>
Title: 8bitworkshop IDE (at 8bitworkshop.com)
<keesj>
Generating a VGA signal is a pretty cool experience specially if you hook it up to a screen.
<dkozel>
:) My goal is to generate an FSK signal so I can hook it up to a radio
<keesj>
then porting that code to litex/migen might be also cool
<dkozel>
I have the loopback/passthrough running in LiteX+GNU Radio, on the Artix 7, over litepcie and Thunderbolt 3.
<keesj>
do you want to generate the data in binary (e.g. i q signals) or .. like .. generate/emulate an analog signal?
<dkozel>
All I need to do now is write the wishbone module and figure out how to route the litepcie data to the custom block and back
<dkozel>
IQ uint16s
<keesj>
that is pretty cool
<dkozel>
uint16 (not signed) :P
<dkozel>
Should be fun. And I have a larger FPGA coming soon so need to get on with this small one before then :P
<keesj>
At FOSDEM .. 2 or 3 years ago there was reseacher that did .. something like that but I think the code was running on the SDR itself. the way you use it the block is really standalone (with input and output) or does it have the full flowgraph on the board?
<keesj>
(I think the FPGA was doing mostly FFT)
<dkozel>
This is still just one sub-graph running on the FPGA and the main runtime is on a host
<daveshah>
tnt: there is a DSP48E1 model in Yosys that should work with cxxrtl. It has been verified against the sim model in Xilinx so should be correct
<dkozel>
We have a huge amount of work going right now (part of why I'm not able to put time into this project) on redoing the runtime to natively support heterogeneous platforms, including auto building gateware and GPU DSP
<dkozel>
but that's probably a conversation better had on #gnuradio-dev. I don't want to wander this channel
<keesj>
yea sorry
<tnt>
daveshah: interesting thanks !
Skip has joined #litex
<daveshah>
What is still missing is a ram model, iirc
Skip has quit [Ping timeout: 245 seconds]
palmer1 has joined #litex
Claude has quit [Ping timeout: 256 seconds]
benh_ has joined #litex
palmer has quit [Ping timeout: 265 seconds]
benh has quit [Ping timeout: 256 seconds]
futarisIRCcloud has quit [Ping timeout: 256 seconds]
levi has quit [Ping timeout: 256 seconds]
rohitksingh has quit [Ping timeout: 256 seconds]
_florent_ has quit [Ping timeout: 256 seconds]
Claude has joined #litex
_florent_ has joined #litex
futarisIRCcloud has joined #litex
levi has joined #litex
rohitksingh has joined #litex
kgugala has quit [Quit: -a- Connection Timed Out]
kgugala has joined #litex
sconklin has quit [Quit: Ex-Chat]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
FFY00 has quit [Remote host closed the connection]