futarisIRCcloud has quit [Quit: Connection closed for inactivity]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 240 seconds]
lkcl has quit [Ping timeout: 258 seconds]
<geertu>
nickoe: Why? Flipping USB connectors is part of our heritage ;-)
<geertu>
s/our heritage/the full USB experience/
lkcl has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #litex
proteusguy has quit [Ping timeout: 264 seconds]
proteusguy has joined #litex
Zguig has joined #litex
<Zguig>
Hi all, is it just me or there was a change somewhere related to ethernet? I don't manage to receive packets with ECPIX-5 boards. I see them going out and being received, but the reply is not catched in Linux... Am I missing something? Some days ago it was working... :(
<Zguig>
What is strange is that boot from tftp is working fine
<Zguig>
So it should mean that at Ethernet core level everything is fine and that the issue is related to Linux?
<somlo>
(this one was built with the added analyzer, so hopefully that's reflected in there somewhere :)
Bertl is now known as Bertl_oO
<geertu>
somlo: Hmm, so no small task to make it fit in the 24K part.
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #litex
lkcl has quit [Ping timeout: 256 seconds]
<somlo>
geertu: it's hit-or-miss even on the versa (45k ecp5) -- don't think a rocket/litex soc can fit on a 24k...
<somlo>
or by "24k part" you mean a xilinx chip? no idea if/how that would work, in that case
lkcl has joined #litex
Zguig has quit [Quit: Ping timeout (120 seconds)]
Zguig has joined #litex
<geertu>
somlo: I did mean the small ECP4 on the OrangeCrab
lkcl has quit [Ping timeout: 240 seconds]
Melkhior has joined #litex
<Melkhior>
Datapoint: using vivado (not an OSS toolchain), the Rocket SoC just fit using 95% of the LUT in a Artix-7 35k ; that's with just memory controller, serial port, sdcard; no ethernet or any fancy options
<Melkhior>
| Site Type | Used | Fixed | Available | Util% |
<Melkhior>
But rocket uses no DSP block at all ? Weird, VexRiscV uses some for the multiplier.
lkcl has joined #litex
lambda has quit [Ping timeout: 246 seconds]
lambda has joined #litex
<nickoe>
geertu: hehe
<nickoe>
(usb)
<somlo>
_florent_, daveshah: here's my attempt at an ecp5 jtag patch for litex: mirror.ini.cmu.edu/litex/litex-ecp5-jtag.patch and here's trying to use that by adding analyzer support for the trellisboard: mirror.ini.cmu.edu/litex/litex-boards-trellisboard-analyzer.patch
<daveshah>
I think something is failing in the OpenOCD integration. Something that I don't see is something telling OpenOCD about the custom opcodes to use (0x32/0x38) to access the JTAGG
<somlo>
would that be in the openocd config file ?
<daveshah>
I'm not sure how that works tbh
<daveshah>
but I know it needs to be somewhere :)
<somlo>
yeah, then I'm screwed :) I know a lot *less* and was just hoping for some easy cut'n'paste, monkey-see-monkey-doo success, but things rarely work out for me like that :D
<somlo>
guess that's how I end up learning things, I'll keep staring at the various moving parts until they slowly and painfully start making sense, eventually, hopefully...
<daveshah>
you could try something like changing "irscan $_CHIPNAME.tap $_USER1" to "irscan ecp5.tap 0x32"
<daveshah>
I think the Xilinx OpenOCD stuff is setting $_CHIPNAME but the ECP5 stuff isn't so this would be a quick way to check (I don't know what the proper fix here would be)
<somlo>
daveshah: that definitely got things started -- I can fire up litex_server
<daveshah>
that's good
<somlo>
running litescope_cli gets stuck "downloading" the vcd file
<daveshah>
there might be timing differences compared to the Xilinx primitive
<somlo>
but that might just be the ecp5 jtagg utilization being wrong on my end
<daveshah>
> o_JRSTN = ~self.reset
<daveshah>
huh does LiteX allow inversion of an output this way (it may well, I've just not seen this before)
<somlo>
I've grepped around for how one would invert a signal, and there's examples like that elsewhere in the code base
<somlo>
I think there's one even in soc/cores/jtag.py further above where I added mine...
<daveshah>
that looks like an input though
<somlo>
oh you mean I screwed up and should have written "i_JRSTN" ?
<daveshah>
no, o_JRSTN is an output
<daveshah>
but I think what you might need to do is output to a temp signal and then assign self.reset to be the inverse of that temp signal
<daveshah>
unless that really is valid syntax for an inverted output
<somlo>
I can try that and see if it makes a difference... I don't get an error and it's done elsewhere, and did I mention cut'n'paste is how I get things done ? :D
<somlo>
but yeah, worth a shot...
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 240 seconds]
<somlo>
daveshah: same behavior with the explicitly negated signal -- I'm going to assume it was OK with the original syntax, and dig elsewhere for why the vcd isn't getting downloaded from litescope_cli...
<_florent_>
somlo: you should indeed use o_JRSTN = self.reset_n and have a self.reset.eq(~self.reset_n) below
<somlo>
but thanks for tracking down the openocd magic in litex_server!
<_florent_>
somlo: also litescope will be stressing the link a bit, that's a bit ambitious for a first test :) I would first test with simple accesses to the scratch register (eventually with litex_client --read/--write/--regs)
<somlo>
_florent_: the "direct negation" syntax is also used elsewhere: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/jtag.py#L31 -- but looking more closely, the negated signal is an "lvalue" (or source to an input), and in my case it's an output, so maybe that's why *I* shouldn't do it like that and it's ok for the line I linked to :)
<somlo>
_florent_ I'm going to try writing (reading still won't work for me over the jtag debug link on nexys4ddr, so I can't rely on it)
<_florent_>
somlo: in the other case it's an input, which works
<somlo>
_florent_ -- I mean writing from litex_cli, and checking from the litex bios on the board itself
<somlo>
reading registers via litex_cli is still not making sense for me on the nexys4ddr, is what I meant to say -- so either I'm doing something wrong, or there's a bug in the analyzer -> jtag -> server -> client read path...
<_florent_>
for bringing this up, I would recommend using a design with a SoC and both uartbone and jtagbone bridge with Litescope on the JTAG signals
<_florent_>
run Litescope over the uartbone to capture the write/read accesses from the JTAG
<somlo>
_florent_: I'm going to try writing to the trellisboard registers via jtag (what I know to already work on the nexys4ddr). We should probably stick to the nexys4ddr to further debug the read-register-over-jtagbone problem, IMHO (fewer unknown unknowns :) )
<somlo>
and writes do *not* make it through over the ecp5 jtagg thing, so back to the drawing board
<somlo>
it does not help that jtagg is practically undocumented (beyond a list of inputs and outputs)
<somlo>
I'm sure there's probably 17.5 things I'm getting wrong about it by just guessing :)
<somlo>
maybe I should put in a RFC-dont-apply-PR if that makes it easier to look at it together?
<_florent_>
somlo: just for info, I'm been using jtagbone the last few days to do bus control/LiteScope since need it on a Kintex7 boards that only has a JTAG connector and haven't reproduced the issue you see on nexys4ddr yet
<somlo>
_florent_ I wonder if it's specific to the nexys4ddr, and/or the bitstream (or analyzer-enabling patch) I'm applying to it
<_florent_>
I'll try to do some tests on the nexys4ddr to see if I reproduce
Melkhior has quit [Quit: Ping timeout (120 seconds)]
Zguig has quit [Quit: Ping timeout (120 seconds)]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 258 seconds]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 272 seconds]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 240 seconds]
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #litex
<nickoe>
Anyone who has some notes on doing boundry scan test practically with openocd and the artix7 somehow?
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 258 seconds]
<nickoe>
On another topic, how does one define the platform for a board where you have the FPGA for a sub module and you want to remap those "pins" to something on that base board and make it more accessible.
peeps[zen] is now known as peepsalot
ambro718 has joined #litex
ambro718 has quit [Quit: Konversation terminated!]
<nickoe>
ok, verified the board could be flashed with nmigen and a couple of LEDs, now I just need to figure out how that RAM and flash works...
<nickoe>
Does the spiflash_model have any real meaning in the platforms ?
<nickoe>
Ok, I think I did define the flash correctly now. Next up the ddr3 stuff :S
<daveshah>
The grouping is arbitrary to make it a bit clearer, Python joins the strings together
<daveshah>
Sorry, not Python joining the strings here but LiteX (I missed the comma)
<daveshah>
same thing though
<daveshah>
Sounds like chip select is always enabled if it is permanently pulled down and has no associated pin, then yes you should be able to remove it
<daveshah>
from the LiteX board file
<nickoe>
is that VREF_DDR3 to be used for anything? it looks like it is the center of a voltage divider on the board
<daveshah>
Yes, although often it doesn't need a pin constraint because it's a fixed pin
<nickoe>
ok, I think it is correct now, although there is a high likelyhood of typos after all those parameters. What is the best way to test this?
<daveshah>
Build a test SoC and see if the memory test passes is pretty much the only way
<daveshah>
Many typos will cause the build to fail
<nickoe>
I am not exactly sure about the SPI flash parameters, but I think they are correct.
<nickoe>
I asume the IOStandard and misc args to those signals are correct, but I don't really know. I just copied the skeleton from another thing that had a DDR3 SDRAM comment to the block.
<daveshah>
It looks decent at a glance
<daveshah>
The next step is to get a target written, if you haven't already
<nickoe>
I don't but I guess I can copy one and replace some bits
<nickoe>
I am new to litex
<nickoe>
and migen in general
<daveshah>
Yeah the target files tend to involve fewer changes than the platform file
<daveshah>
Mainly it will be setting it up with the right RAM chip etc
<nickoe>
I guess I could copy the arty_s7.py
<daveshah>
Yep
<nickoe>
mmm, it has a "from litedram.modules import MT41K128M16" :S Is that something that should match my RAM?
<daveshah>
Yes
<daveshah>
If it's not in litedram.modules already then you'll need to add it
<daveshah>
nrows is 2^14=16384, ncols is 2^10=1024, based on the number of row and column address bits
<nickoe>
so that is for 128Mb x 16 ?
<nickoe>
deduced from the "Density and Addressing" table on the front page?
<daveshah>
Yes
<nickoe>
and the fact that NT5CC128M16IP-DI is listed as "128M x 16" organization. ok
<daveshah>
yup
<nickoe>
What about the timings then?
<nickoe>
why is that set as tREFI=64e6/8192 for some of the other devices?
<nickoe>
the table has a temperature dependent value, tREFI(us) 4 Tc<=85 °C :7.8, Tc>85 °C :3.9
<daveshah>
that is 64ms (the total refresh time) divided by 8192 rows, I think
<daveshah>
I think just copying the 64e6/8192 should be fine
<nickoe>
under section "Extended Temperature Usage" it talks about supporting extended temperateture ranges, and having a faster refresh rate. Is that because leakage current is higher?
<daveshah>
given DRAM is somewhat standardised, I would expect most of the timings to be the same as another 128Mx16 part
<nickoe>
at higher temperatures?
<daveshah>
Yes
<nickoe>
ok, so the last thing, the speedgrade timings
<mithro>
nickoe: Get an Arty A7....
<nickoe>
ugh, build_waxwing.sh: line 4: xst: command not found
<nickoe>
mithro: I mean; I have another board now with DDR
<mithro>
nickoe: That needs ISE....
<nickoe>
mithro: ehh, no
<mithro>
xst == ISE
<nickoe>
oh.. then I did something wrong, this has an artix7
<nickoe>
oh, it detected P=waxwing ... mmmm
<nickoe>
is there some place I need to specify a new platform to make it be detected properly when I set PLATFORM and sources the enter env?
<nickoe>
oh, right. I added the "target" in another litex-boards repo
<nickoe>
instead of the litex-buildenv
<nickoe>
ok, so far so good, some fiddling with the "target" needed, but it is getting late here. GN. https://dpaste.com/3P3FRECM4
<tpb>
Title: dpaste: 3P3FRECM4 (at dpaste.com)
<daveshah>
yep looks like it is just getting confused by the lack of a reset in the platform (if the board doesn't have anything usable as a reset button you should just be able to remove the reset from the target)