<mithro>
sb0: Do you know if or1k has Linux support?
<mithro>
sb0: oh sorry, I should just Google it myself - OpenRISC is officially supported in the Linux kernel since version 3.1
<mithro>
sb0: we ran into the problem that lm32 has gcc support but no Linux support and the or1k has no upstream gcc (but looks like Linux support)
<cr1901_modern>
Linux can finally be compiled with LLVM?
<mithro>
cr1901_modern: last I heard they were getting pretty close
ylamarre has quit [Quit: ylamarre]
<sb0>
rjo, since there is Constant now, can fslice and freversed go?
<cr1901_modern>
sb0: Did you write the wishbone module in Migen before the API change?
<sb0>
what api change?
<cr1901_modern>
you're moving wishbone out of Migen
<sb0>
well then obviously the answer is yes
<cr1901_modern>
(Hey, _florent_ could've done it lol)
<sb0>
ah. i thought you were asking when it was written.
<sb0>
and yes, I wrote most of it
<cr1901_modern>
No, I'm working with a softcore that's not 100% compat with wishbone. You moving wishbone out has compelled me to try writing my own address decoder and bus records in the spirit of migen.bus.wishbone.
<cr1901_modern>
I've noticed that when doing InterconnectShared, you connect wires manually even though Records have a connect() function, and a parameter to exclude signals
<cr1901_modern>
Were the modules written back before Records had that param to exclude signals, or did you have another reason to manually connect everything
<sb0>
it will go to misoc, not be removed completely
<cr1901_modern>
I understand that. The reason I'm writing my own module is b/c wishbone is actually suboptimal for this. I implemented wishbone for this softcore mainly b/c it was "there" and to avoid code duplication of SRAM/peripheral interconnects. But since I'm testing the new migen api, well... :P
<sb0>
there is no specific reason for manual connection
rjo_ has joined #m-labs
<cr1901_modern>
okay, I didn't think so, I just wanted to make sure.
<rjo_>
sb0: for me there seems to be quite a bit more momentum behind or1k vs lm32. other than that and llvm and coding idiocyncrasies i can see little relevant difference.
<rjo_>
imho a migen implementation or even a good verilog scrubbing (with a really rough wire brush) might go a long way
<cr1901_modern>
An lm32 migen impl would be interesting
<cr1901_modern>
I mean, how bad could it be to do?
<rjo_>
and then wasn't there a problem with multiple lm32 instances due to the config/parameters stuff?
<rjo_>
sb0: yes. not exporting fslice and freversed seems correct. does slicing and reversing work for Constant? I don't remember wether I added tests for that.
<rjo_>
sb0: and some way of transforming a given thing to a Value (Signal or Constant) would be good. maybe Value.wrap(1) == Constant(1); Value.wrap(a) == a iff isinstance(a, Signal) ?
<rjo_>
cr1901_modern: wild guess: a week of very focused work. there is an excellent test suite (credit goes to mwalle i guess) that makes this very well guided, and starting from rewriting the verilog, then iterativevely refactoring would probably be the way to go.
* cr1901_modern
mulls this over. Sounds fun.
<cr1901_modern>
If there is a pressing need/desire to do this, I will seriously consider it
<rjo_>
there are obviously large fudge factors hidden here. migen experience, processor architecture experience, lm32 experience etc might each be a factor of two.
<rjo_>
and anyway i have never done anything like this so i actually have no idea...
<cr1901_modern>
I have experience with the first two. I haven't actually written lm32 code, but it reads like a MIPS or NEC V20 clone
<cr1901_modern>
wow, not v20... NEC v810* clone. About a decade off.
<cr1901_modern>
First, actually publishing some Migen code I'm proud of would be nice though
<rjo_>
and i never understood why or1k and lm32 have so many GPRs. the compilers never seem to use them and even then they are costly as they are all save-restored in isrs...
<cr1901_modern>
I'm pretty sure interrupt latency is a joke on modern virtual memory CPUs
<rjo_>
cr1901_modern: little migen project that should see some use would be adding bscan2bpi to that openocd bscan2spi thing. e.g. for bitstreams of today the 128 MBit SPI flashes are almost full. half of the kintexes and all of the virtexes will need different flashes.
<rjo_>
for embedded RT stuff isr latency is relevant. see arm and the enormous complications they go through with things like FIQs...
<cr1901_modern>
Hrm :/
<cr1901_modern>
Is this an extension to your "JTAG programmer on FPGA" project you ontributed to openocd?
<rjo_>
sb0: also, why did you remove the Constant.eq() overload?
<sb0>
because you can still hit that problem in another way: if you encapsulate Constant in Cat, and then use Cat.eq
<rjo_>
hashes are also deterministic.
<sb0>
it's not really a hash, it's a unique identifier, and it needs to be deterministic from one python process to another
<rjo_>
ok. you defer to later tools. that's good.
<sb0>
it's also always increasing, which is used to generate numeric suffixes in the same order as program execution in the namer
<rjo_>
but the collision resolution breaks usual notion of determinism. but i know what you are doing.
<sb0>
it's deterministic if you don't change the code, and almost deterministic if you make minor changes
<rjo_>
sb0: do i really have to do a.eq(a + C(1)) now?
<sb0>
no
<sb0>
+ autowraps
<rjo_>
ah. i overlooked that.
<rjo_>
why do you add underscores to Value and Operator when you also use __all__? just to tell people that theses classes are not made for their consumption?
<rjo_>
what if i want to do isinstance(a, migen.Value) in my code to check for migen-icity?
<rjo_>
sb0: in _Value.__bool__() can't you just return hash(self) == hash(other) inside the if?
<sb0>
I don't use __all__ in structure. was thinking of simply adding underscores to the imports
<sb0>
hmm, true
<rjo_>
adding underscores to the imports?
<sb0>
though it will break if some other python object is added to the dictionary, which happens to have a hash that matches a duid
<sb0>
unlikely, but from a purist perspective ...
<sb0>
import builtins -> import builtins as _builtins
<sb0>
and the like
<rjo_>
and L136, 167, 205, 235, 466, 545, 581 all look like the same code: refactor as Value.wrap(x)
<rjo_>
technically Python __hash__()es are not unique. you might want to use __id__() for that
<rjo_>
where do you want to do that renaming on import?
<rjo_>
or maybe just migen.wrap(x). seems generic and clear.
<sb0>
the code is small and the exception text is different
<sb0>
there's no __id__, and id() will break when comparing two Constants
<rjo_>
hash(self) == hash(other) won't work either because they return machine ints.
<rjo_>
why does __id__ break on Constant comparison?
<rjo_>
i don't see how the difference in exception message is helpful. the backtrace pretty much contains that information. and that code will crop up in other places.
<rjo_>
damn. id() is even worse than hash()...
rjo_ has quit [Quit: leaving]
<sb0>
two Constants with the same value can be two different objects, with two different ids
<whitequark>
also note id()s can get reused if you don't also keep the reference to the object along...
rohitksingh has joined #m-labs
atgreen has quit [Remote host closed the connection]
ylamarre has joined #m-labs
ylamarre has quit [Read error: Connection reset by peer]
ylamarre has joined #m-labs
ylamarre has quit [Quit: ylamarre]
ylamarre has joined #m-labs
rohitksingh has quit [Ping timeout: 255 seconds]
rohitksingh has joined #m-labs
ylamarre has quit [Quit: ylamarre]
mumptai has joined #m-labs
mumptai has quit [Remote host closed the connection]
mumptai has joined #m-labs
ylamarre has joined #m-labs
<rjo>
sb0: i had the impression that you could overload __id__() but that ain't the case. and even literals have a) non-stable id()s and b) reuse ids...
<whitequark>
are you trying to make a weak map or what?
<whitequark>
oh, nevermind, read the backlog
rohitksingh has quit [Ping timeout: 268 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
ylamarre has quit [Read error: Connection reset by peer]
<rjo>
and now there are even 1000 LUT RISC-V implementations in useful verilog... https://github.com/cliffordwolf/picorv32 looks very multi-cycle though. but should be cool where speed does not matter and the pain of CDCs outweighs.
<mithro>
kristianpaul: you had a question about my board?