<Fallenou>
lekernel: my previous attempts (before you sent me minisoc) were failing because I was not setting a reset signal to the "cd_sys" clock domain, I was not using any SRLE16 primitive
<Fallenou>
with the SRLE16 code snippet, it works now :)
<lekernel>
yeah
<lekernel>
would be interesting to rewrite LM32 with FHDL, that would solve little problems like resets and the slightly messy include file
<lekernel>
the latter could become a real problem in a multicore system
<lekernel>
also, when we have direct FHDL to netlist, we could synthesize MM SoC :)
azonenberg has quit [Read error: Operation timed out]
<Fallenou>
that would be pretty cool :!)
<wpwrak>
speaking of which, aren't there already open source tools that do a verilog to netlist conversion ?
<wpwrak>
that way, you could take migen output, mix in the "native" blocks, and process that
<lekernel>
no, there aren't
<lekernel>
been thinking about your "mixed language" thing wpwrak and I start to like it...
<wpwrak>
good :)
<wpwrak>
look at all the different worlds, take the best from all of them
<lekernel>
also, you can use that as an output language to check what metaprogramming did
<lekernel>
ie output the same language but without any python bits
<wpwrak>
yup, regression tests are important for this sort of project
<lekernel>
can be a nicer debugging aid than opening the generated verilog
<lekernel>
and death to verilog anyway :)
<wpwrak>
well, you could still use the basic bits of verilog. they're not so bad
<lekernel>
yeah, but kill the event-driven model
<wpwrak>
expression syntax, most of the syntactical structure, e.g., all that's fairly clean and intuitive. they veer off into silliness with their macro capabilities, though
<lekernel>
I'd say 90% of ASIC engineers don't understand it anyway, as illustrated by the prevalence of " <= #1 " assignments in synchronous blocks
<wpwrak>
well, if that's what you really need ... :)
<lekernel>
sometimes, there are still some silly and complicated to fix comb loops in the migen output as well
<wpwrak>
so icarus doesn't always solve the halting problem. well, what's new ? :)
<larsc>
well it's not the halting problem
<larsc>
it's just a simple bug
<wpwrak>
yeah. a very special case of not solving the halting problem :)
<lekernel>
the funny thing is all simulators do a different thing
<wpwrak>
but does icarus advance the time ? or does it stay at t = 0 ?
<larsc>
it shouldn't
<larsc>
should all be in the same delta cycle
<larsc>
but on the other hand verilog doesn't know about delta cycles
<lekernel>
it's the halting problem in general, yes. but remember you are designing synchronous hardware, so your comb loops are supposed to settle in a short time.
<lekernel>
and the event driven model does not know anything about synchronous hardware, which is wrong
<wpwrak>
so you basically want to reduce it to either "assign" or "always @(...edge ...)", no other forms of always
<larsc>
even with the event driven model loops settle in short time, zero time to be exact.
<larsc>
problem is when they don't settle, but they won't settle in hw either in that case
<lekernel>
I mean time in delta-cycles
<lekernel>
and yes
<lekernel>
but for some verilog simulators, loops that settle in hw don't settle in simulation
<lekernel>
including some big expensive simulators
<larsc>
interresting
<wpwrak>
can an always also execute then a signal it assigned to but doesn't change ?
<wpwrak>
e.g., always @(x) y <= y+1
<wpwrak>
and somewhere else x = 1; x = 1; x = 1;
<larsc>
that's undefined
<wpwrak>
if the answer is "yes", the endless loop would be more or less valid
<wpwrak>
hah ! :)
<larsc>
I think
<wpwrak>
there we go
<larsc>
you just shouldn't do this kind of thing
<wpwrak>
of course, that makes @(*) rather dubious
<wpwrak>
in a way, always @(*) makes assign somewhat redundant, doesn't it ?
<larsc>
in what way?
<wpwrak>
in the sense that assign could just be expressed as always @(*), couldn't it ?
Hawk777 has quit [Read error: Operation timed out]
Hawk777 has joined #milkymist
<larsc>
kind of
<larsc>
you can do more in a process though
<larsc>
and an assign is more like aliasing the signal
<wpwrak>
you mean you have more means to express your operation ? or do you mean you can do operations (without entering undefined territory) an assign can't do ?
<wpwrak>
i could imagine an event counter, but then that's probably undefined (see the example above)
<larsc>
you can for example use a case statement
<wpwrak>
couldn't you express this in an "assign" as well ?
<larsc>
yes
<larsc>
but not as nicely
<wpwrak>
i'm looking at it from a simplification point of view: if always @(*) can replace assign and is more comfortable, then you probably shouldn't have assign.
<larsc>
well assign foo <= bar; is easier than always @(*) begin foo <= bar; end
<larsc>
and there is a a subtile difference
<wpwrak>
you could just group several assignments in one block, like migen does
<larsc>
why would you?
<wpwrak>
to avoid the extra construct. keep the language simple
<larsc>
assign assigns a signal to a signal and <= assigns a value to a signal
<wpwrak>
that's an implementation detail :)
<wpwrak>
also blocking vs. non-blocking seems a bit unnatural
<wpwrak>
if you assume that you have a synchronous design anyway, i don't think you need both
<larsc>
yea, that's what they messed up in verilog
<larsc>
they only had blocking in the beginning
<wpwrak>
that's what i'd do, too
<larsc>
no
<larsc>
blocking is horrible
<wpwrak>
i'd put my faith in data flow analysis
<wpwrak>
that is, the semantics would be those of blocking. nice and easy. the implementation could be something very different.
<larsc>
the problem with blocking is that is not deterministic
<lekernel>
it is deterministic if the only thing you do with the value is read it in a non-blocking assignment somewhere down the same always block
<wpwrak>
how about making blocks (semantically) atomic ?
<lekernel>
how about not having blocks?
<wpwrak>
how do have different clocks without blocks ?
<lekernel>
the only reason you may want blocks is for variables/blocking assignments
<wpwrak>
also migen has them. all sorts of sync plus one comb
<lekernel>
and clocks ofc
<larsc>
well, you want blocks to structure things
<wpwrak>
well, perhaps one could do it like this: use blocks strictly for scoping and compound statements, like in c
<lekernel>
no, python provides better ways to structure things
<larsc>
but we are not talking about python now, are we?
<wpwrak>
[...] ... naw, that thouht i was developing doesn't go anywhere nice
<wpwrak>
lekernel: python still has blocks :)
<wpwrak>
i'm not a great fan of python's indentation syntax. it looks nice enough in most cases, but it gets in the way when debugging code
<Alarm__>
wpwrak: I try to write a patch Flickernoise to drive a projector DMX address 1 with a midi console. It works with DMX table but not with the console: http://pastebin.com/WEx8x7C9
<Alarm__>
wpwrak: why ?
<Alarm__>
wpwrak: ?
<wpwrak>
looks as if it should work. does anything happen instead ? error or such ? the controller numbers ( (1, 1), (1, 2), (1, 3) ) are correct ?
<wpwrak>
i don't know about DMX, though. do if it's a problem on the DMX side, i wouldn't know what it means.
<Alarm__>
wpwrak: f I put DMX2 = 1.0 then the red lights.
<Alarm__>
wpwrak: if I put DMX2 = 1.0 then the red lights.
<wpwrak>
maybe try avoid binding the control directly to an output variable. i.e., instead of dmx2 = range(fader1); do tmp = range(fader1); dmx2 = tmp
<wpwrak>
as far a i remember both should work, but maybe there's an issue
<wpwrak>
you could also test your fader selection. i.e., make sure you got the numbers right. if you got them wrong, simply nothing happens
azonenberg has joined #milkymist
bhamilton has left #milkymist [#milkymist]
bhamilton has joined #milkymist
<Alarm__>
wpwrak: in last line, I put: DMX2 = tmp, I get the following error: "Value must be a near constant EOF"