#milkymist IRC log for Sunday, 2011-02-20

lekernelplain integer constants in Verilog are 32 bits and ...signed?!00:17
wpwraklekernel: like in C ?08:13
larsci don't know what the standard says, but for a language like verilog it wouldn't make much sense for interger constans to have any size at all08:45
wpwraklarsc: hmm, for general math, it would be useful. languages that require an excessive amount of declarations tend to just invite problems. e.g., think of pascal's ranges.11:46
wpwraklarsc: but i don't know verilog well enough to really criticize the language design.11:47
larscwpwrak: what i meant was that it would make sense for them to have no upper limit.11:51
larscsince those are consts and known at compile time you know the size they'll require11:52
larscand can create a signal large enough to hold that const11:53
larscif your const is only 4 bits wide you wouldn't want to instantiate a 32-bit signal.11:53
larscand artificially limiting the size to 32-bit would also disallow you from using larger consts which will result in crude hacks when dealing with signals with more then 32 bit wide11:56
wpwrakhmm. that still wouldn't solve the math problem, though. is "3+1" 2 or 3 bits ?11:56
larsclike 'if signal[63:32] == MY_CONST_UPPER and signal[31:0] == MY_CONST_LOWER"11:57
wpwrakdunno how verilog handles "large" integers. hopefully not in an overly ugly way ;-)11:57
larscwpwrak: consts are known at compile time11:57
larscso you know that 3+1 is 411:57
wpwrakhow about 2-3 ? :-)11:58
larscnot different11:58
larscthe actual representation of the number will depend on the context11:59
wpwrakso you would have "infinite" integers ? e.g., 2-3 would be "*010" - "*011" = "*1" ? with *0 = an arbitrary number of zeroes, *1 = an arbitrary number of ones ? that might work.12:02
larsc2-3 would be -112:02
larscthe bit representation then would depend on the context12:03
larscif you would assgin it to an 4-bit wide signed signal you would get 111112:05
larscif you would assign it to a 16-bit signed signal you would get 1111111....12:05
larscif you would assign it to a unsigned signal you would get an error12:05
wpwrak(24+4) >> 1 assigned to 4 bits would then be an error ?12:07
wpwrakor, better, (14+4) >> 1. would it be a) error, b) 9, c) 1 ?12:08
wpwrakbecause you cannot represent the result of 14+4 in 4 bits12:08
larscbut (14+4) >> 112:08
wpwrak(well, assuming the usual conventions)12:08
wpwrakand with how many bits do you calculate the intermediate results ? does the "value size is target size" rule not apply there ?12:10
larscwell, at least how i would model it12:11
wpwrakthey probably just didn't want to get into arbitrary-precision math.12:13
larscbut you have to12:15
larscthough floating point numbers is a different topic12:16
wpwrakdoes verilog have floats ? wow. best to replace them just as rational numbers then ;-)  so 0.5 = 1/2, and you can represent 1/10 precisely.12:18
larsci think they have12:18
wpwrakbut you see that the arithmetic "core" gets quite heavy if you make such provisions. just declaring the world to be 32 bits is a lot easier :)12:19
larscand stupid ;)12:19
larscif you think about it, it really doesn't make any sense at all12:20
larsc(to limit the number space)12:21
wpwraki would have to come up with a nice example where you actually depend on truncation of higher digits :)12:21
wpwrakmaybe with xor.what's N ^ 3 ? is it N ^ 00...011 or N ^ 11...111 ?12:23
wpwrakexamples like  a = b ^ ~c. there you quickly run into ambiguities if not everything has the same size. maybe you could solve them with a two-pass solver, though. first pass would determinate the worst-case size, and then the seocnd pass would perform all calculations with that size.12:26
wpwrakgah, determine12:26
wpwrakthree-pass actually. first, your propagate from operands to results. second, yoiu12:28
wpwrak'd propagate (sizes) back from results to operands. third, you'd do the calculation.12:28
wpwrakwhat was the verilog notation for size again ... size'value ?12:29
wpwrakso (14+4) >> 1 would be (4'14+3'4) >> 1'1 before pass 1, after pass 1 maybe (*) 5'(5'(4'14+3'4) >> 1'1), and after pass 2 something like 5'(5'(5'14+5'4)) >> 1'1).12:34
wpwrak(*) depends on how shift is defined. e.g., does a right-shift reduce the size of the value or does it leave it the same, filling the high bit(s) with zero(es) ?12:35
wpwraki think it gets quite nasty when you get down to the details. particularly when combining arithmetic with bit-ops.12:39
larscone think that indeed wouldn't work with that concept is bit-wise negation12:42
larscor maybe any bit-wise operation at all12:42
larscbecause you haven't choosen a bit representation of the number yet12:43
larscyou'd have to cast to a specific representation first12:51
larscin vhdl for example you have to_unsigned and to_signed constructs12:51
larscwhich take a integer and a wide12:51
larscto_unsigned(3, 4) would be 001112:52
wpwrakyes, you would either have to treat bit-negation as signed or maybe even introduce a sign-extended unsigned type12:54
wpwrakor maybe just the "infinite prefix" approach would work, i.e., the *0/*1 i mentioned above12:54
larscnah, disallow bit-wise operations on integers12:55
wpwrakhehe ;-)12:55
larscwe take it for granted nowadays how a number is represented12:56
larscbut with hdls the implementator can choose its own.12:57
larscyou have to differentiate between the abstract concept of a number and the actual implementation13:00
larscand a number per se has no bits13:00
larscbits are specific to a binary implementation13:01
larscanyway, i'll have to go the train. 'll be back in a few hours13:03
larscwpwrak: consider the following example:15:56
larscalways @(posedge clk) begin; if counter = 15 begin; counter = 0; end else begin counter = counter + 1; end end15:57
larscswitch(counter) begin case 0: doA; case 1 doB; case 2: doC ...15:58
kristianpauland counter initial value is?15:58
larscdoesn't matter ;)15:58
larscif you choose a binary representation for counter you'd end up with a 4-bit register, an adder and 16 comparers.15:59
larscyou could use a 16-bit shift register though, were each bit represents one state of the counter16:00
kristianpaulis see, the points is dempostrate that you cant take for granted numeric representations as in software..16:05
wpwraklarsc: yes, that's basically an optimization problem, where you replace one construct with a different construct that has the same semantics. similar to the use of calculated jumps to implement "case" in a C compiler.16:06
kristianpaulalso when you use a for to parametrice the generation of some logic16:06
wpwraklarsc: also, whether the shifter really makes sense also depends on what happens in the cases. e.g., if case N just stored value N+1 in some output register, then I'd keep the counter ;-)16:10
wpwrak(to make it more interesting and plausible, add one exception)16:11
larscthe example assumes counter is not used elsewise16:11
larscwpwrak: but even if you'd store the counter to a register in one of the cases it should still be far more efficent to use the shifter16:12
larscones and zeros are cheap16:12
larsca compare unit is not so cheap16:12
wpwrakprobably, yes. but it all really depends on what exactly happens in the rest16:12
kristianpaulalso in the avaliable resources on fpga, as larsc said, what is cheap and what not16:13
kristianpaulregisters are expensive :-)16:13
larscyes. and i hope that helps my point that for hdl languages you should not expect a certain bit representation of an integer16:14
kristianpaultotally agree16:14
kristianpaulor who knows wpwrak can force llhdl to follow that rule ;-)16:14
kristianpaulnot follow*16:14
kristianpaulat the end is a resource problem too, so fpga market can change the rules about that too16:16
wpwrakthe bit representation defines the semantics in an easily understood way. perhaps not easily understood per se, but given that this is basic CS knowledge, few engineers will have difficulties with it16:16
larscin languages like C we can safley assume that a integer is stored as binary number, because the underlying processor will always use that representation16:16
wpwrakif you introduce your own set of rules, people need to wrap their head around them16:17
kristianpaulwpwrak: problem is logic and how you wire it up,16:18
kristianpaulimagine that using fluids :p16:18
wpwrakthat you generate in the end does not have to have any resemblance to the model chosen to define the semantics of the definition of the design16:18
larscwpwrak: i don't introduce my own rules, it's simple plain math ;)16:19
wpwraklarsc: for integers, yes. but already word size can be manipulated. consider an 8 bit microcontroller. a compiler can often tell that this "32 bit" integer is really only used as 8 bit.16:19
larscit's still a binary number16:20
wpwraklarsc: well, you suggested that you wanted to separate bit ops from arithmetic. that sounds like a new set of rules ;)16:20
kristianpaulwait wait, you said microcontroller, thats a high level talk i think16:22
larscactualy bit- and arithmetic operations are two differnent sets of operations. in programming languages they just tend to be defined on the same datatype16:22
wpwrakit's still a binary number but already different. there are more complex cases. e.g., loop optimization often removes counters or combines them16:22
wpwraklarsc: ah, so -X = ~X+1 is coincidence ? ;-)16:23
wpwrak(i was waiting for this one ;-))16:23
larscwpwrak: yes it is16:24
larscit's not true if you use a ones-complement binary representation16:25
wpwrakcorrect, yes. so you would leave the representation of numbers completely undefined ? e.g., they wouldn't even have to be binary ?16:26
wpwrakso  reg & 2  would be an error16:26
wpwrakreg & (cast-to-binary) 2  then ? :)16:26
kristianpaulwhat you want to do with: reg & 2 ?16:27
wpwraktest/access/whatever one bit16:27
kristianpaulthats 2 bits i think16:27
larscwpwrak: you have to differentiate between interger types and binary types16:28
wpwrakbinary 00...010 -> one bit is set. and zeroes all the other bits in "reg"16:28
larscreg would probably be a binary16:28
larscof a certain size16:29
larscso using a bitwise operation on a binary and an interger would cause an implicit cast on the interger16:29
larscand you would only get an error if the interger is too large for the binarys space16:29
larscand yes, in vhdl your example would be an error. you'd have to use "reg & to_unsigned(2, 4)" or "reg & d'2"16:31
wpwrakcan you also to_unsigned(reg, 4) ?16:32
wpwrakor only literals/constant expressions ?16:33
larscwould be possible16:34
larscyou can define integer signals16:34
wpwrakso vhdl tries to be pascal-like while verilog is more c-like16:34
kristianpauland llhdl.. :-)16:36
wpwrakfor code generation, this may not make much of a difference, of course. you'll have to be able to handle these cases in either case16:36
larscif no bit operations are used on an binary type it is probably converted to an integer by the compiler16:37
wpwrakthe concept of a "natural" word size is problematic. also in programming languages. in theory, the only proper way of doing it would be to have no implicit sizes and each variable would have to be declared with a range.16:37
wpwrakbut in practive, this would be insane. e.g., you would have to change declarations even if you only change algorithms a bit (for fencepost errors and such)16:38
wpwrakand it gets even nastier if a variable only exceeds its range when the variable is no longer used afterwards.16:41
wpwrakthe "natural" word size helps there, because it's usually "more than enough". so while this is sloppy, it also avoids having to spend a lot of attention on micro-managing things.16:42
kristianpaulwrong direction, thats expensive !16:43
wpwrakhmm ?16:43
kristianpaul"natural" word size16:44
wpwrakno, it's cheap :-) (in traditional programming languages)16:45
larscwpwrak: i think you are still thinking too much in 'traditional' terms16:45
wpwrakin a hardware description language, i would expect the synthesis to ignore any sized that aren't nailed down anyway16:45
wpwraklarsc: (ignore sizes) like in your counter+case vs. shifter example16:46
wpwraklarsc: what i'm saying is that one should differentiate from the semantics of the representation and the implementation16:47
larscyea, thats basicaly what i said16:48
wpwraklarsc: if the representation assumes a "universal" 32 bit word size, that shouldn't prevent the implementation from doing something completely different16:48
larscat least i think16:48
wpwrakheh, so we agree ? :)16:48
larscbut why assume 32bits in the first place?16:48
kristianpaulhere we go again :-)16:49
wpwrakmay be one case of "everything is a vax". let's be happy that they didn't follow the "everything is a pdp-11" mantra, or it would be 16 bits ;-)16:49
kristianpaullets a sume a "universal" n bit word size :-)16:50
larscwpwrak: and now image you want to implement a 64bit cpu16:51
wpwrakalso, for a C programmer, this convention, along with the convention that numbers are arithmetic and binary, would be natural. so there would be fewer bugs caused by wrong "common sense"16:51
wpwrakyeah, that's an interesting question. how do you do >32 bits ?16:52
larscwpwrak: well you can use arithmetic and binary operations on binaries, but not on integers.16:52
wpwraka major departure from C, which is not a nice thing to do in a language that aims to be C-like16:53
kristianpaulBut sintax is lookig compared with vhdl, (at least for me)16:54
kristianpaul nice looking*16:55
kristianpaulC-like modeling16:55
kristianpaulnot implementation16:55
kristianpaulbut yes, you should be aware of the non-comon sense rules :-)16:56
larscwpwrak: if you wanted c like integers you could easily do something like typdef signed[0:31] int3217:28
larscbut imposing that artificial limit on all numbers doesn't appear as a good idea to me17:30
larscfor 'traditional' programs you have that limit because it is not artificial17:31
larscas you said it's the natural word size17:31
rohwpwrak: >32bit? use proper amounts of ram (yes, i have seen data sources in use > than 4g address room)17:42
rohor 'store type information' is also nice. one could use 2-4 bits easily there. i'd like 36bit or 72bit computers please. with an io type checking hw on every bus interface17:43
wpwraklarsc: well, did they solve it in verilog ?17:54
larscwpwrak: what?17:56
wpwrak64 bit values18:05
larscwell you simply define a register of width 64bit18:11
larscreg foobar[63:0];18:11
larscactualy it is 'reg [63:0] foobar;'18:12
wpwraklarsc: so there are no technical problems going beyond 32 bits after all ?18:25
wpwrakah, bliss and happiness :-)18:31
kristianpaulmore o less, the hapinesss will be a N bit system18:31
larscyou suggested to limit the size to 32bit thats why i ask how would implement a 64bit cpu in such an environment18:32
wpwraknaw, i didn't suggest to limit the size. you said integer constants were 32 bit only. i merely looked for justifications why (a) fixed size(s) would lead to more consistency in an environment where this is the case (as opposed to a dynamic-precision system)18:36
rohwhy limit at all?18:37
larscwpwrak: i never said that18:37
larscwpwrak: i said that imo there shouldn't be a limit on integer size18:37
wpwrakoh, sorry, that was sebastien. too many l* ;)18:41
lekernelwpwrak: in Verilog you can define constants with an optional size specifier19:47
lekernele.g. 13'd78 defines a 13-bit unsigned constant with value 78 (in decimal)19:47
lekernel3'b101 3-bit with value 101 in binary19:48
lekernelbut if you just write, say, 78, it's 32-bit and, I think, unsigned19:48
lekernel(and decimal)19:49
lekernellatest llhdl gadget: graphviz output23:38
Fallenouhéhé graphviz does nice stuff23:39
lekernelwell, it depends23:40
lekernelit works well for trees, like this23:40
lekernelbut if we don't duplicate signals to make the graph a tree, the result is a mess23:40
lekernelI'd also like to use graphviz to display the netlist (instead of the proprietary and Java EDIF viewer in PlanAhead)23:41
lekernelbut I'm not sure it'll work great23:41
kristianpaulFallenou: hi23:47
kristianpaulCan you try ttcp in your side, but this time from qemu to host23:48
Fallenouoh never tried23:49
Action: Fallenou stars his VM23:49
kristianpaulLast night i wasnt able to send the 1Mb file, but flicernoise patches we're ok..23:49
kristianpaulI mean ftp -> get from flicernoise23:50
kristianpaulI ran ttcp and you can see the output..23:50
Fallenoudo you mount the patches directory via NFS ?23:50
kristianpaulnope, i dint try NFS yet...23:51
kristianpaulremenber flicernoise run a ftpd server23:51
Fallenouyep so you send the patches via ftp23:52
mwallemh there is a div and mod opcode, but no description for it.. lol qemu has only support for divu/modu23:52
kristianpaulFallenou: send went good, from the host to flickernoise, but viceversa seems is not working23:53
kristianpaulFallenou: but this time i dint experience RX fifo wearnings, as i'm just sending from flickernoise23:53
kristianpaulSo i want to confirm this test on qemu.. as you already had this setup on your side, so i'm asking you to try23:54
mwallethe lm32_decoder.v in milkymist doesnt seem to support div/mod neither23:56
Fallenoukristianpaul: it worked for me23:56
mwalleanother typo in the documentation i guess23:56
Fallenouttcp -t -s from rtems23:56
mwallegn8 :)23:56
kristianpaulhttps://twitter.com/xlerb/status/38679508189978624 :O23:56
Fallenouand ttcp -r -s from the ubuntu23:56
Fallenoumwalle: gn823:57
kristianpaulFallenou: size of file?23:57
Fallenouwhich file ?23:57
kristianpaultry upload something about 1Mb23:57
kristianpaulit worked for me <- file?23:57
kristianpaulahh wait23:57
Fallenounop i am talking about your ttcp test23:57
Fallenouyou just asked me to do23:57
kristianpaulyes yes23:57
Fallenouok i am uploading the results23:57
Fallenoustrange my copy paste seems cleaner than yours :o23:59
kristianpaulYeah thats other thing...23:59
kristianpaulI'm using screen to connecto to the pot23:59
--- Mon Feb 21 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!