<aw_>
wpwrak_,  i'd like upload it to wiki if you don't mind. ;-)
<wpwrak_>
easy :)Â Â ps2pdf file.ps file.pdf
<aw_>
how about convert to jpeg?
<wpwrak_>
(regarding the content) to my shame, i have to admit that i still haven't found a way to get it to calculate the lowest point in each sweep. all i get is the lowest point in all sweeps.
<wpwrak_>
hmm, better png
<aw_>
yeah..ok to png
<wpwrak_>
convert print.ps print.png
<wpwrak_>
well, s/print/file/g :)
<kristianpaul>
now what adam need to apt-get install to make all this work? :-)
<aw_>
good, i converted done. tks
<wpwrak_>
for better quality, you can use: cat file.ps | gs -sDEVICE=ppmraw -sOutputFile=- -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -q - | convert - file.png
<aw_>
hmm..but background is messy
<aw_>
OMG
<aw_>
try again
<wpwrak_>
kristianpaul: (install) yeah. fear the dependencies ;-)
<wpwrak_>
aw_: that's how the experts do it :)
<aw_>
85
<wpwrak_>
aw_: bonus points if you can type the command without looking at your cheat sheet ;-)
<aw_>
wpwrak_,  supposedly i am not defitely expert though. ;-)
<wpwrak_>
aw_: if you memorize this command, you can pass as one :)
<aw_>
90
<wpwrak_>
aw_: did the long command work ?
<aw_>
95
<wpwrak_>
aw_: and, and while you're at it, you may want to rotate and trim/crop: ... | convert -trim -rotate 90 - file.png
<aw_>
wpwrak_, try them after 100 , tks SIR. ;-O
<aw_>
100
<aw_>
wpwrak_, done that long command work, but right top corner equation is trimmed some. :(
<wolfspraul>
aw_: how are things going? any new problems?
<wpwrak_>
yeah, there are frequently problems with sheet sizes/bounding boxes. this will fix it:
<wpwrak_>
aw_: great ! oh, and if you want it bigger, you can add the option -rDPI to the invocation of "gs". the default is -r72Â Â bigger numbers increase the number of pixels
<aw_>
wpwrak_, used a r600 now, updated, tks.
<wpwrak_>
wow. r600 will be monstrous ;-)
<lekernel>
wpwrak_, lattice use synplify for synthesis, which has few bugs
<lekernel>
but neocad-like tools for p&r, like xilinx
<wpwrak_>
lekernel: so you suspect the delays are there to cover up some problems in the verilog ?
<lekernel>
they are here to cover up problems with simulation
<lekernel>
the delays do nothing in synthesis
<lekernel>
one of the things that are very bad with verilog is that simulation results are non deterministic in some cases ...
<lekernel>
that's an horrible time sink and an horrible source of bugs
<lekernel>
(in synchronous synthesis, one of those non-deterministic cases is picked up in a deterministic way, and then you get differences between simulation and implementation ...)
<wpwrak_>
hmm. and you can't make sure only one case remains ?
<lekernel>
yeah but then you lose useful language features
<wpwrak_>
sounds as if the problem would go away if synthesizer and simulator shared the same interpretation/preferences
<lekernel>
or you can use vhdl, which does not have this problem
<wpwrak_>
yes yes, you've posted that one at least twice already ;-)
<wpwrak_>
that too :)
<wpwrak_>
dunno. i find the approach of splitting things into "major" and "minor" phases a bit kludgy as well
<lekernel>
those issues are also irrelevant for synchronous systems, like most FPGA designs...
<lekernel>
they just create problems for free here
<wpwrak_>
why can't simulation be synchronous as well ?
<lekernel>
there are some synchronous simulators, e.g. Verilator - but last time I checked, it had bugs
<wpwrak_>
ah well :)
<wpwrak_>
seems that the real problem is that simulator and synthesizer don't quite agree on what to do. apparently, even to the point where the simulation does not do what the verilog says, if i understand your complaint correctly ?
<lekernel>
wpwrak_, yes, or you can get simple stupid behaviour in simulation
<kristianpaul>
not going to learn VHDL anytime soon..
<wpwrak_>
lekernel: (archiving) oh dear. that world of closed source and no revision control must be so much fun ...
<wpwrak_>
lekernel: (stupid behaviour) i'm still a bit puzzled about that bit. so that would be something that does what the verilog says but it still not what - you think - the verilog means ?
<lekernel>
look at the sigasi links
<lekernel>
it could mean that something like this
<lekernel>
always @(posedge clk) reg2 = reg1;
<lekernel>
always @(posedge clk) reg3 = reg2;
<lekernel>
would correspond to 0, 1 or 2 registers, depending on how the simulator orders the events ...
<lekernel>
while the designer obviously wants a shift register with 2 stages
<lekernel>
to remove the ambiguity, one could use the non blocking assignment "<=" instead of "="
<lekernel>
which is the right thing to do in this example
<wpwrak_>
great, problem solved :)
<lekernel>
but there are more complex cases where the blocking assignment "=" is useful
<lekernel>
e.g.
<lekernel>
reg = reg + 1;
<lekernel>
if(reg > 5) reg = 0;
<wpwrak_>
there, the ambiguity is resolved by the data dependency ?
<lekernel>
no, the problem is here that you have a register "reg" that uses blocking assignments and is probably read from a different "always" block
<lekernel>
the code can be rewritten with the non blocking assignment as
<lekernel>
reg <= reg + 1;
<lekernel>
if(reg > 4) reg <= 0;
<lekernel>
but if there was a more complex operaion than "+1", it quickly becomes messy
<wpwrak_>
so the reg = reg+1  and the  if (reg > 4) reg = 0  would be in different blocks ?
<lekernel>
no, those two would be in the same always block. but typically you'll want to read "reg" from another place
<lekernel>
the geninterp18 design is theoretically incorrect, since I rely on a particular ordering of events (which matches the deterministic one of synchronous design synthesis) - the code simply happens to work with the way gplcver orders the events...
<lekernel>
a lot of designers use this kind of dirty workaround
<wpwrak_>
mmh, bad
<wpwrak_>
such things have their equivalent in the software world of course. you'd be surprised by how many programs break if you make "char" unsigned, even though ANSI C clearly states that "char" can be signed or unsigned. and then there are things like word sizes, etc.
<lekernel>
yeah, such things should not exist
<wpwrak_>
so yes, each language is surrounded by a "grey zone" of unspecified behaviour that people just expect to be in a certain way, but that isn't guaranteed. seems to be one of these cases.
<lekernel>
it's plainly bad language design
<wpwrak_>
i don't know. there are things you cannot find. especially not in concurrent designs.
<wpwrak_>
"you" = a compiler or such
<larsc>
wpwrak_: not to count all those programs which would brake if you'd make char 7-bits ;)
<lekernel>
wpwrak_, vhdl solved this problem of verilog with the use of 'variables'
<lekernel>
which are like verilog's regs, but local to the equivalent of an always block
<lekernel>
so you do not have this nasty problem which arises when you have communication between always blocks with blocking assignments
<wpwrak_>
larsc: that should be even more fun :) well, there were the old CDC mainframes, with 6 bit characters :)
<wpwrak_>
so vhdl removed the problem of synchronizing access to global variables by removing global variables ?
<lekernel>
maybe you should read the sigasi posts :) I can't really explain it better than that
<wpwrak_>
my so far purely theoretical understanding of these things doesn't go quite deep enough to grasp the finer points of what he wrote, but to me it seems that there are simply two paradigms that describe different things, where vhdl has a very rigid timing model and verilog is more similar to a traditional programming language that gives the compiler a lot of freedom to order things in the way it likes best
<lekernel>
it gives the _simulator_ some non-determinism, which does not have any purpose except wasting people's time
<wpwrak_>
based on this, i would expect vhdl to easily lead to designs that are either inefficient (because you spread them out over to many clock cycles) or cluttered (because you have to cram everything into one place to escape the rigid timing barriers), while verilog would suffer many of the usual misconceptions we know from C in concurrent designs
<lekernel>
no, there is no disadvantage to the vhdl variable
<wpwrak_>
it would still seem to me that the non-determinism is fundamental to the language semantics. one way to avoid it would be to tighten the language until there can no longer be any ambiguity, but that may lead to overly complex and inefficient designs (basically, micro-management)
<larsc>
read the articles ;)
<lekernel>
nah... maybe you should read up a bit on how simulators, synchronous designs, and logic synthesis work :)
<wpwrak_>
the other path would be to break the simulation into two parts: the execution, and the validation of the concurrent behaviour
<wpwrak_>
larsc: reading he articles does't tell me how well the ideas work in practice :)
<wpwrak_>
(breaking the simulation into two parts) the execution would then share a set of conventions external to the language/definition proper that would make it generate the same behaviour as the synthesis
<wpwrak_>
while the validation would actively explore the ambiguities and ensure that all interpretations are valid
<wpwrak_>
that way, your simulation could be directly compared to real hardware (as in matching simulated and real scope traces)
<lekernel>
there's an easier way to ensure same behaviour in simulation/synthesis: the vhdl delta delay algorithm and the use of the 'variable' container ....
<wpwrak_>
while your validation would tell you where you left ambiguities that conflict with your design (and it would allow you to keep ambiguities that don't)
<lekernel>
verilog should copy it... and remove those stupid reg/wire containers as well
<wpwrak_>
can't you just do the same by never using = on global variables in verilog ?
<wpwrak_>
well, in llhdl, there's your chance to clean up some things ;-)
<lekernel>
yes, but then you lose the functionality of the blocking assignment
<wpwrak_>
think of gcc. that one also has a lot of extensions. some of which later got incorporated into standard C
<lekernel>
llhdl is for synchronous synthesis, and synthesizers already do the right thing
<lekernel>
the problem is only for general (not necessarily synchronous) simulation, and it also impacts simulation of synchronous systems
<wpwrak_>
(losing blocking assignments) you could still use it on non-global variables, no ?
<lekernel>
yes, but in turn some tools seem to have issues with mixing blocking and non-blocking assignments in the same always block...
<wolfspraul>
wi 45
<wolfspraul>
sorry
<wpwrak_>
so again, if your set of conventions to avoid ambiguities is to use synchronous synthesis (i have to admit that it's not intuitively clear to me what exactly this means, though), then perhaps all you really need is a simulator that follows the same conventions
<wpwrak_>
lekernel: (broken tools) well, but that's not a defect of the language :)
<wpwrak_>
actually, i wouldn't be surprised if the average verilog tool would be better quality than the average vhdl tool, simply because verilog looks less forbidding
<wpwrak_>
and maybe it's deceptive as well, in making things look friendly even if these things are inherently unfriendly
<wpwrak_>
btw, C also has its crutches. e.g., the linux kernel is written in a dialect of C with rather interesting extended semantics, which include things like memory barriers.
<wpwrak_>
memory barriers are something that doesn't exist in C. there's only the largely implementation-specified "volatile". but the language has no concept of, say, "shared memory"
<wpwrak_>
but that's where you can help a bit with dialects :)
<larsc>
the por
<wpwrak_>
the linux kernel language is at the same time also a subset of C, because there are many constructs gcc warns about (some of these warnings are very useful, others are of questionable value) and there are more constructs that are frowned upon by other human or automated reviewers
<larsc>
the problem with non blocking assignments is, that if you don't put them in synchronized blocks you've effectivly created an endless loop
<lekernel>
hm?
<larsc>
or maybe not
<lekernel>
can you give an example?
<larsc>
yes, but the example leads to an endless loop with blocking assignments too, so...
<wpwrak_>
lekernel: btw, in your code, things like  o_r = o_r - 18'd1;  is the  18'd  because the synthesizer, when doing the calculation, doesn't see that the target is 18 bits wide ?
<lekernel>
i'm not sure if those prefixes are needed at all with modern tools ...
<wpwrak_>
good :)
<wpwrak_>
they look like maintenance nightmares. e.g., if you change the variable size and then have all those repetitions of the size scattered all over the code. a bit like excessive use of casts in C
<wpwrak_>
by the way, if you want to brutally maximize concurrency, you should look at Promela. it's a very nice and light-weight language, a bit like C
<wpwrak_>
it's used for modeling concurrent behaviour (and then validating properties of it)
<wpwrak_>
one way to view it is that you put a number of assertions into your "program" and the validator will then execute some or all of the possible paths, and tell you what happened when it hits an assertion failure
<wpwrak_>
"what happened" includes the full execution history
<kristianpaul>
i agree that closed-sourced tools may leed to unfair critism to hdl languages, ie verilog :)
<wpwrak_>
kristianpaul: indeed. and lekernel has it within his grasp to change the rules of the game. maybe have an option --good-sheep for llhdl, which makes it accept all the "standard" verilog he can stomach. if the option is omitted, extensions become available and constructs he dislikes produce nasty warnings. in each version, there can be more extension and warnings. a bit of constant prodding goes a long way ;-)
<GitHub91>
[milkymist/master] TMU prefetch: top level design - Sebastien Bourdeauducq
<mwalle>
larsc: ?
<mwalle>
lekernel: btw is it possible to support full speed devices?
<mwalle>
if there will be a real usb host controller someday
<lekernel>
yes, full speed devices should work
<larsc>
mwalle: still there?
<lekernel>
in theory, simply by changing the navre firmware. in practice, you will probably uncover enough pesky bugs to keep you busy for several days ...