sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
cjbe__ has joined #m-labs
cjbe_ has quit [Ping timeout: 240 seconds]
cjbe__ has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined #m-labs
<rohitksingh_work>
sb0: Hi! I have few questions. If the program in going to be entirely in I-Cache, what would be the upper limit of the cache size (i.,e the program size)? Also, If program is guaranteed to be in I-Cache always, and since we do not need bus access for that, can we replace current mor1kx Cappuccino I-Cache with an emulated, ideal I-Cache with 100% hit (inside the module it will be simple Dual-port BRAM itself, along with Cache signal emulation) Or
<GitHub162>
[smoltcp] pothos commented on pull request #65 3888f11: I can remove all empty cases and the unreachable which I added to see if something was missed. Then if would just be the following:... https://git.io/vF0eh
<GitHub62>
[smoltcp] LuoZijun commented on issue #71: ok, thx for your reply. https://git.io/vF0vP
stekern has joined #m-labs
stekern has quit [Read error: Connection reset by peer]
stekern has joined #m-labs
<rjo>
sb0: imo #844 needs to be fixed for 3.1. having underflows go unreported is a big problem.
<rjo>
sb0: yes. the rtm sounds fine for developing the 1000base-x phy. good idea
<rjo>
sb0: i was also leaning towards gearboxing.
<GitHub190>
[smoltcp] phil-opp opened pull request #73: Store plain DeviceT instead of Managed<_> in EthernetInterface (master...patch-a) https://git.io/vF0W5
cjbe__ has joined #m-labs
<GitHub49>
[smoltcp] whitequark commented on issue #73: I *think* the idea was to make it possible to store a trait object, but Device is no longer object-safe anyway, right? It doesn't seem important to me to allow an EthernetInterface with a borrowed Device, and even if it is, we can restore this functionality. https://git.io/vF0Wp
<GitHub89>
[smoltcp] phil-opp commented on issue #73: I'm not sure about the object safety of `Device`, but I will take a look. https://git.io/vF0ld
<GitHub68>
[smoltcp] whitequark closed pull request #73: Store plain DeviceT instead of Managed<_> in EthernetInterface (master...patch-a) https://git.io/vF0W5
<travis-ci>
m-labs/smoltcp#386 (master - 4ae84ab : Philipp Oppermann): The build passed.
<GitHub51>
migen/master 2e73dbd Robert Jordens: kasli: fix ddr3.a7
<GitHub51>
migen/master a79badb Robert Jordens: kasli: add internal VREF
<cr1901_modern>
shuffle2: Just for my own curiousity, do you still have that example code where CSR inference was failing even when you made sure all your classes inherited from AutoCSR?
<cr1901_modern>
shuffle2: Full example, please (should've specified)
<shuffle2>
i've already print()-debugged it...issue is that the scan func doesn't recurse into _submodules
<shuffle2>
ie you can't use self.submodules += ThingUsingCSR() to instantiate such classes. have to use self.submodules.name =
<cr1901_modern>
Oh, good job, thanks! That's probably (?) intentional in that case
<shuffle2>
it's an undocumented feature heh
<cr1901_modern>
shuffle2: Yea, looked over the source, that's intentional/as you described. misoc only checks whether immediate children have get_csrs(), and while >>
<cr1901_modern>
named submodules that inherit AutoCSR do have get_csrs(), the internal attribute _submodules that collects all submodules (both named/anonymous) does not
sb0 has quit [Ping timeout: 240 seconds]
sb0 has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<GitHub91>
[smoltcp] phil-opp opened issue #74: Bug in tcp option parsing? https://git.io/vF0Fi
<sb0>
rohitksingh, the program memory size should be configurable at bitstream compilation time
<cr1901_modern>
sb0: What does "pnd" in "_build_pnd" stand for if you remember?
<sb0>
prefix and name dictionary I think, isn't that spelled out somewhere?
<cr1901_modern>
It might be, I haven't devled that far into the namer code yet
<rohitksingh>
sb0: Thanks! One more doubt. You had written "The I-Cache becomes the program ROM". So if I-Cache (which is already stored in BRAM) becomes the program ROM, do we need separate memory for tags? Wouldn't it be unnecessary? Currently in direct mapped I-Cache which artiq is using, BRAMs are used for tag ram. Although if we want to not risk breaking anything, then that would be the way to go. Mor1kx in artiq currently doesn't use LRU replacement (since direct
<sb0>
rohitksingh, obviously the tags must be removed.
<sb0>
and "replacement" doesn't make sense anymore, there is no bus and nothing to replace the content with
<sb0>
it's not a cache anymore, just a ROM
<rohitksingh>
sb0: Thanks! Much vivid now! Also, why aren't we using "espresso" implementation of mor1kx instead of cappuccino? What were the motivations for using cappuccino?
<sb0>
I don't remember, see the code/docs. iirc the cappucino is faster or has more features
<rohitksingh>
anyways we aren't going to use Cache as well as MMU
<rohitksingh>
I can check the code for espresso implementation though
<rohitksingh>
and I'll consult on the #openrisc channel
<sb0>
for this fixed-program CPU, feel free to use the smallest CPU that can run Rust. performance or features don't really matter for that use case.
<rjo>
rohitksingh: what are you working on?
<rohitksingh>
excellent! this give much more leeway!
<rohitksingh>
*gives
<rohitksingh>
rjo: Optimizing BRAM usage of mor1kx in artiq
<sb0>
that's for processing drtio aux packets on the rtm
<sb0>
also programming the 5324 etc.
<rjo>
rohitksingh: ack. good.
<sb0>
btw has anyone programmed the 7a15t as if it were 7a35t? is there more DRM than changing some chip ID and fixing up the bitstream crc?
<rohitksingh>
sb0: So, we can change the implementation via this parameter -> https://github.com/m-labs/misoc/blob/master/misoc/cores/mor1kx/core.py#L36 Only thing remaining would be to add a single-cycle access to Instruction ROM/BRAM from cpu without wishbone, plus (if needed) probably use the other remaining port as a generic wishbone slave so that BRAM can be updated while the design in running (and obviously when processor is in reset)
<rohitksingh>
that's would be really nice if we could use a35t's bitstream on 15t....iirc die is same for both, there was some news quite long back
<sb0>
ah, that other port is a good idea. maybe the program could be loaded from the wishbone bridge using it, which avoids bitstream compilations
<rohitksingh>
yeah, that exactly I was thinking :)
<sb0>
make it optional though (via compile time switch)
<rohitksingh>
yeah
_whitelogger has quit [Ping timeout: 250 seconds]
_whitelogger has joined #m-labs
<rjo>
sb0: you'll also have to alter the JTAG DR routing. chances are slim.
<sb0>
JTAG DR?
<sb0>
what for?
<sb0>
ah
<rjo>
the bitstream length is the same. but i guess the rest of the bscan arch may be different.
<sb0>
it's the same chip
<rjo>
no its not. they read fifferent idcodes for example.
<sb0>
and vivado uses the whole surface - they don't limit it by having only some defined area
<sb0>
another way of doing it is to modify vivado to remove the extra resource count check
<rjo>
you looked at the floorplan?
<sb0>
yes
<sb0>
briefly
<rjo>
let me check the bsdls...
<rjo>
they are the same except for the idcode.
<rjo>
worth a try.
<rjo>
... worth a try doing runs with the same logic on a 15t and 35t and then interpret and use the delta on bigger logic that would not fit a 15t.
<felix_>
only difference between those chips is the idcode. the 6 older artix7 chips are only 3 different dice. and yes, patching the idcode and then fixing the crc works
<rjo>
is the idcode even in the bitstream?
<felix_>
yep
<rjo>
at 0xf2?
<felix_>
in the beginning of the bitstream is the idcode that gets compared with the idcode in the device
<felix_>
uh, iirc there's some instruction in the bitstream for the comparision
<rjo>
i see another delta at 0x3f54c but that might be spurious. or the checksum.
<felix_>
write idcode register is the command and the idcode in the bitstream are the 4 bytes after that
<felix_>
the idcode is only in the beginning of the bitstream. have a look at ug470 bitstream composition
<larsc>
if you don't have that command does it fail or succeed?
<rjo>
you don't even have to fix the crc. it's optional.
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.3.0/20170811091919]]
<felix_>
sure, you can also remove the crc check, but i'd only do that to test things
<rjo>
larsc: leave out the idcode packet? maybe.
<felix_>
ah. haven't tried that
<rjo>
felix_: is there a bitstream converter (35t/50t -> 15t)?
<larsc>
'After the device is synchronized, a device ID check must pass before the configuration data frames can be loaded'
<larsc>
I guess that answers my question
<felix_>
haven't seen a publically available bitstream patcher. i used a hex editor; not sure about the two other people who tried that. releasing that would imho be not a good idea. i was curious if the rumors that some SKUs share a die are true and it's something you have to look at if you want to understand how the a7 bitstream works ;)
<larsc>
is it just ink on plastic or is it like with processors where sub-blocks that don't work can be disabled?
<felix_>
since you can place different components inside the chip on all possible positions i tried (at least everyting i tried succeeded if the total number of brams/... was not bigger than the software enforced limit), my guess would be that the chip is fully tested and the fuse bits for the idcode are burned at the end of the production line. haven't really verified that though
<rjo>
the idcode comparator change is one epsilon more than ink on plastic.
<GitHub163>
[smoltcp] whitequark commented on pull request #75 e9e9ce3: You should take a look at how other enums are defined. There's a macro that writes conversion functions for you:... https://git.io/vFu37