<_florent_>
I find it can be very useful to support that it allows for example to pass a slice to a function or module and use slice into it.
<_florent_>
here is a dirty workaround I've implemented that seems to work: http://git.io/R6EPhw
<larsc>
and verilog doesn't allow a slice of a slice?
<Fallenou>
_florent_: to avoid your migen api to be broken and be forced to update your verilog github repos, you can add migen as a git submodule inside your github projects
<Fallenou>
so that you can say "I want to use this Migen SHA-1"
<Fallenou>
and when you feel like it, you can update Migen SHA-1 and make the according changes in your code to update to the new API
<Fallenou>
then your code is never "broken" by an update of your dependency
<lekernel>
_florent_, there are more cases where it would not work
<lekernel>
I think a good way to solve it is whenever you are not slicing a signal directly, create an intermediate signal and assign it the value to be sliced, and then slice that intermediate signal
<lekernel>
that can be done easily using fhdl.visit.NodeTransformer
<lekernel>
verilog is really annoying sometimes
<_florent_>
fallenou: in fact I'm using my Migen fork
<lekernel>
d[64:1][32:1][16:1] can have clear semantics, I don't understand why it's not allowed
<Fallenou>
_florent_: ok, but someone cloning your github repos could not know that, could it ?
<lekernel>
do parentheses help? (iirc no, but let's check)
antgreen has quit [Ping timeout: 258 seconds]
<_florent_>
Ifallenou: yes I have to describe it in my projects
<lekernel>
the 'assign to slice' case is more problematic too, so it would be great if parentheses worked
<Fallenou>
_florent_: yes that's a good alternative to using git submodules :) sometimes it can be a pain to use ... but I'm used to it now so I may have a compulsive need for it now :p
<Fallenou>
time to see someone!
<_florent_>
lekernel: ok thanks, I'm going to check the parentheses
<wpwrak>
lekernel: the problem with exposing verilog restrictions at the migen language level is that you destroy the nice abstraction migen aims to provide
<lekernel>
I'm not arguing that this should not be fixed - it should
<wpwrak>
good :)
<lekernel>
choosing the always@* form + reset when only slices of the signal are assigned should be done too (and would fix your bitgen problem)
<_florent_>
hmm..parentheses don't seems to work with verilog..
<lekernel>
yeh that's what I thought...
<lekernel>
so for reading slices, the temporary signal solution is easy enough
<_florent_>
ok I will have a look at NodeTransformer
<lekernel>
for writing slices, I think you have to handle messes like {{a[3:4], b, {c, d[30:10]}[4]}, e}[10:0] <= some_value
<lekernel>
maybe by also storing some_value in an intermediary signal, then dissecting the mess and assign a slice of some_value to a, b, ... and/or e individually
<wpwrak>
yeah, i think you need to process the semantical structure of such expressions. it's not just a matter of substituting text
bhamilton has joined #milkymist
<_florent_>
is it already possible to slice a Cat like this: c.eq(Cat(a, b)[10:0])?
<lekernel>
no
<lekernel>
it will output {b, a}[10:0]
<wpwrak>
_florent_: what a cruel thought ! slicing a poor little kitten ...
<lekernel>
which verilog doesn't like
<_florent_>
ok, it will be needed if you want {{a[3:4], b, {c, d[30:10]}[4]}, e}[10:0] to be working
<lekernel>
slice are the other way around in migen (like python) btw
<lekernel>
so you probably mean c.eq(Cat(a, b)[0:10]) and you can also write [:10]
<_florent_>
yes sorry, I'm aware of that, juste mixing langage...
<_florent_>
just
<wpwrak>
lekernel: it may help to clarify things if you'd make a drawing in the manual. your description needs a lot of context to make sense.
<lekernel>
the only case which is implemented correctly now is directly slicing a signal
<lekernel>
there are bugs in all other cases
<_florent_>
maybe it's not useful to support all the others cases
<lekernel>
I think it is useful to some degree
<lekernel>
not only to have a clean abstraction, but there are also practical cases where it's useful
<lekernel>
but I'd agree they are a minority of cases
<wpwrak>
and it helps to make programs more readable
<wpwrak>
a language that has all sorts of quirks and exceptions very quickly becomes a playground for voodoo programming
<wpwrak>
but then, i think migen may be an interim solution. a way to gather experience with a "better" HDL. at some point in time, you may decide to make changes to the syntax that exceed what you can do in python, and either make some sort of preprocessor/precompiler, much like you're hiding ISE now, or even make your own language without translating to python
<_florent_>
at least even it's not implemented, Migen should raise an "NotImplemented Error" instead of generating incorrect verilog code.
<_florent_>
but it's maybe not easy to cover all theses cases
<lekernel>
JFII
<wpwrak>
i think when you're able to detect it, you could probably just support it as the programmer intends :)
<lekernel>
yes :)
bhamilton has quit [Quit: Leaving.]
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
<lekernel>
_florent_, what would you think about changing the Migen license to BSD?
<lekernel>
larsc azonenberg
<larsc>
lekernel: yes please!
<larsc>
would allow me to use it at work
<_florent_>
same for me, I will be able to use it for my customers or the will be able to use if directly
<_florent_>
*they
<Fallenou>
bsd powa :)
<wpwrak>
in general, picking one of the "standard" licenses is vastly preferable over a homegrown or bastardized license
antgreen has joined #milkymist
antgreen has quit [Ping timeout: 245 seconds]
<lekernel>
yay, my customer likes my "top-notch-MBE lab time accepted as payment" quote
<lekernel>
let's first redefine what "DIY LED blinker" means, then do something useful like single photon avalanche diodes ...
* lekernel
needs a second life
<wpwrak>
Molecular Beam Epitaxy ?
<wpwrak>
and you told them you need that to blink LEDs ? :)
antgreen has joined #milkymist
<Fallenou>
nice so you eventually have access to such "toys" :)
<Fallenou>
let's make transistors!
<Fallenou>
let's make Milkymist SoC asics with MBE!
<lekernel>
I'm not sure if they can do complex patterns for eg CPUs...
<lekernel>
and I'd start with a 6502 instead, which already has well known and well tested masks
<lekernel>
or a 4004
<lekernel>
the avalanche diodes I'm pretty sure they can make them, and quantum physics experiments at home are cool too
<wpwrak>
and long as you don't find a low-energy way to produce black holes or strange matter ... :)
<lekernel>
I should also find a lab that has good CVD machines (they don't have any) and then try to run a "make your own diamond from pencil lead material" workshop at some future EHSM ;)
<lekernel>
note sure you can use actual pencil leads though. they probably have lots of contaminants...
<wpwrak>
lekernel: so .. how's the issues situation now ? you said the clock is stable ?
<wpwrak>
regarding your failing channel B, could it be a problem with the HPD resistor ? (R27)
<lekernel>
well the PLL never loses lock anymore, even with resolutions higher than 640x480 60Hz
<lekernel>
but there's still a whole circus of bugs after that... no further improvement at all
<lekernel>
so I'll stick with the plan of sending raw data to DRAM
<lekernel>
and check I don
<lekernel>
't just try to process garbage
<lekernel>
haven't looked at the ch B issue yet
<wpwrak>
what may also help is to try to decode the frame structure and output frames on VGA. that way, you may be see at one glance how things are wrong, particularly when problems are somewhat infrequent
<lekernel>
non-problems are somewhat infrequent :) for example a horizontal pixel counter displays "640" in something like 2% of the cases, and some random values 98% of the time
<wpwrak>
you can now calculate the statistical probability of just randomly picking 640 ;-)
<lekernel>
and that's when disabling inter channel synchronization... absolutely nothing works when it's enabled
<wpwrak>
well, start with one channel ...
<lekernel>
well it's statistically significant I think ;)
<lekernel>
and I constantly have to deal with ISE breakage all the time, this stuff is really frustrating
<lekernel>
and of course, breakage only after those 15 minutes of compilation...
<wpwrak>
they should switch to code generation bugs that are activated at run-time, with a delay timer. that way, it'll take even longer to find them
<lekernel>
oh, it happens too...
<lekernel>
on the M401, ISE was generating subltly broken code for LM32 that let all sort of software running correctly, but crashed the Linux kernel for some obscure reason
<larsc>
wpwrak: or non-deterministic reconfiguration
<lekernel>
fortunately, the bug was somehow related to the CPU cache, so one day someone tried to run Linux with the caches disabled and it worked ...
<lekernel>
on spartan6, with the exact same verilog code, Linux works with the caches... and I think they have fixed it for virtex4 now as well
<wpwrak>
nice. these are all good bugs, ideal for engineers working for stable companies and interested in long-term job security :)
<wpwrak>
(annual progress report: MTBF is up 50% from last year. still many bugs to work around.)
<larsc>
at somepoint your workarounds create more bugs than they fix
<wpwrak>
yeah, that's when you should find an excuse to go to a different project :)
antgreen has quit [Ping timeout: 260 seconds]
jimmythehorn has joined #milkymist
<larsc>
I think that's why Xilinx is pushing vivado ;)
<wpwrak>
you mean they lost control of their code ? nice ;)
<larsc>
nobody's brave enough to work on the ISE codebase
antgreen has joined #milkymist
<wpwrak>
or maybe it already ate all the programmers who got too close
<davidc__>
lekernel: if migen was BSD, I could use it for work; and therefore do bugfixes/feature stuff on work time [with the intent of getting it upstream, ofc]
<davidc__>
lekernel: [well, BSD, or L?GPL with generated-verilog-output-is-not-considered-derived exception]
jimmythehorn has quit [Quit: jimmythehorn]
<lekernel>
davidc__, cool, thanks for the feedback. what do you work on?
jimmythehorn has joined #milkymist
<davidc__>
lekernel: Embedded network security stuff. Can't give too much detail, sorry :(
<davidc__>
lekernel: but all FPGA deployed stuff
* wpwrak
hates those GMP, MPFR, and MPC dependencies of gcc
<azonenberg>
lekernel: I personally don't have a use case for migen since i already have a tool that does what i need
<azonenberg>
that said, i am in favor of BSDing everything in general
<wpwrak>
hmm, "checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES."
<wpwrak>
let's see what google know about that ..
<wpwrak>
ah, that's where the libstdc removal comes from :)
<lekernel>
you can also disable c++ entirely - no software in milkymist-ng requires it
<wpwrak>
a wise decision ;-)
<wpwrak>
"milkymist-ng/verilog/lm32/submodule/rtl/lm32_cpu.v does not exist"
<wpwrak>
all there is is verilog/lm32/lm32_config.v