doFlame(&numeric_std);

#vhdlのnumeric_stdな猿共と再度flameしてみた． :P

07/25 21:03:01 hiyuh
     hmm
07/25 21:03:31 hiyuh
     i did migrate std_logic_arith to numeric_std on my current proj.
07/25 21:04:06 hiyuh
     but i think numeric_std still sux in my style/use.
07/25 21:04:49 hiyuh
     anybody have good example code which use numeric_std elegant?
07/25 21:04:56 hiyuh
     s/use/uses/
07/25 21:06:39 hiyuh
     MatthiasM, NULL[0] ^^ :)
07/25 21:06:44 MatthiasM
     :)
07/25 21:07:25 MatthiasM
     there is not much to say - if you have a signal/variable which is
     used in computations, then declare it as (un)signed
07/25 21:07:29 Sordran_
     hiyuh:
     http://www.dz.ee.ethz.ch/en/information/hdl-help/vhdl-sources.html
07/25 21:12:00 hiyuh
     hmm
07/25 22:17:16 bpadalino
     hiyuh: yeah, what's the issue ?
07/25 22:21:23 hiyuh
     one of issues I hate numeric_std is it breaks port compatibilty.
07/25 22:21:26 hiyuh
     b/c all of mine was std_logic, std_logic_vector, range constrained
     integer or custom type.
07/25 22:22:22 hiyuh
     i know inner std_logic_vector() wrapping makes it compatible,
     but it's very eyesore.
07/25 22:24:00 bpadalino
     so don't convert to slv at the port level
07/25 22:24:08 bpadalino
     if it's an unsigned number - keep it an unsigned number
07/25 22:24:14 bpadalino
     preserve context as much as possible
07/25 22:28:13 hiyuh
     nope, for lazy simulation, I did input ascending/descending number
     to data port. it's data, not unsigned/signed.
07/25 22:31:26 hiyuh
     and another one I hate is to declare unsigned/signed signal/variable
     and computing w/o unsigned()/signed().
07/25 22:32:21 bpadalino
     you can always overload your functions .. and add your own package
07/25 22:33:12 hiyuh
     if you recommend overloading, i won't use numeric_std TBH.
07/25 22:33:26 hiyuh
     it's pain to me atm.
07/25 22:33:44 bpadalino
     numeric_std removes ambiguity from your code - if you find it to
     be a pain, then live with the ambiguity
07/25 22:34:40 hiyuh
     then plz show me that ambiguity which comes from std_logic_arith?
07/25 22:35:56 bpadalino
     a <= b + x"abcd"
07/25 22:35:58 bpadalino
     what did i  just do
07/25 22:38:27 hiyuh
     every time I compute std_logic_vector, I always do it w/ explicit
     unsigned()/signed(). and also I don't use hexadecimal/binary
     presented std_logic_vector for any computation.
07/25 22:39:45 bpadalino
     congrats - but it doesn't remove the ambiguity that can happen
07/25 22:39:47 bpadalino
     use whatever you want
07/25 22:41:17 hiyuh
     promote me more, why that doesn't remove the ambiguity?
07/25 22:42:45 bpadalino
     because you can still abuse it
07/25 22:44:38 hiyuh
     hmm
07/25 22:48:17 bpadalino
     i understand numeric_std makes your code look "ugly" if you do a
     lot of casting
07/25 22:48:47 bpadalino
     answer is to do less casting
07/25 22:54:48 hiyuh
     I'd like to say trivial explicit casting is not eyesore to me.
07/25 22:54:57 hiyuh
     atm i don't like numeric_std's implicit type guessing to compute.
07/25 22:55:02 hiyuh
     b/c to see which function is used, it needs to see their
     declarations.
07/25 22:55:49 bpadalino
     guessing ?
07/25 22:56:39 hiyuh
     signal a : signed; signal b : signed; signal c : signed; ... some
     line of code ... c <= a + b; -- numeric_std use.
07/25 22:59:10 hiyuh
     + of "a + b" is "signed + signed". but to figure out that, it needs
     to see their declaration.
07/25 22:59:40 MatthiasM
     the issue why code may look ugly is that it is not cleanly designed -
     eg when writing software you have to carefully define the types of
     variables, parameters and return values
07/25 23:00:05 bpadalino
     how is that not any different than how it would happen with
     std_logic_arith ?
07/25 23:01:16 hiyuh
     my std_logic_arith use looks like,
07/25 23:01:17 hiyuh
     signal a : std_logic_vector; signal b : std_logic_vector; signal
     c : std_logic_vector; ... some lines of code ... c <= signed(a)
     + signed(b);
07/25 23:02:00 bpadalino
     is a or b or c a signed or unsigned number ?
07/25 23:02:05 bpadalino
     wow, that's all sorts of crazy
07/25 23:03:19 bpadalino
     nothing stops you from going c <= unsigned(a) + signed(b) ;
07/25 23:03:24 bpadalino
     so it's really just a bunch of bits
07/25 23:04:22 hiyuh
     I mean arg type and computation is one set.
07/25 23:04:26 hiyuh
     signal a : signed; signal b : signed; signal c : signed;
     ... some line of code ... c <= signed(std_logic_vector(a)) +
     unsigned(std_logic_vector(b));
07/25 23:04:41 hiyuh
     is it valid for numeric_std?
07/25 23:04:56 bpadalino
     yes
07/25 23:05:24 hiyuh
     if so, declaration is not for force to use proper computation.
07/25 23:06:07 bpadalino
     if i saw unsigned(std_logic_vector(b)) in a code review, i think
     my red flags would go up
07/25 23:06:18 bpadalino
     but if i saw signed(b) - i wouldn't think twice
07/25 23:06:40 bpadalino
     numeric_std doesn't stop you from being an idiot - it just makes
     it harder
07/25 23:07:17 hiyuh
     yeah
07/25 23:08:33 bpadalino
     they're supposed to be a set of functions which help you
07/25 23:08:42 bpadalino
     if you don't find them helpful, don't use them
07/25 23:09:22 hiyuh
     but if i stick std_logic_arith, MatthiasM will bitch me. :P
07/25 23:09:52 MatthiasM
     sure
07/25 23:14:30 bpadalino
     so learn to quit writing ambiguous code
07/25 23:16:09 hiyuh
     signal a : signed; signal b : signed; signal c : signed; ... some
     line of code ... c <= a + b; -- (1)
07/25 23:16:12 hiyuh
     signal a : std_logic_vector; signal b : std_logic_vector; signal
     c : std_logic_vector; ... some lines of code ... c <= signed(a) +
     signed(b); -- (2)
07/25 23:16:54 hiyuh
     to review code, (1) needs to check declaration and computation. (2)
     needs to check computation only.
07/25 23:17:27 hiyuh
     that's why I hate numeric_std atm.
07/25 23:17:30 bpadalino
     d <= unsigned(a) + signed(b) ;
07/25 23:17:45 bpadalino
     does not enforce that a is a signed type
07/25 23:18:07 bpadalino
     if you want to be loose, and not have matthiam bitch at you -
     use verilog
07/25 23:18:15 bpadalino
     but in a strongly typed language, learn to deal with it
07/25 23:18:17 MatthiasM
     hiyuh: with (2) you have to check that a is used in the same way
     everywhere
07/25 23:18:52 bpadalino
     also - if you pass a out a port as a slv, there is no guarantee it
     will be maintained as that representation later on
07/25 23:19:00 bpadalino
     which only causes more confusion
07/25 23:19:53 MatthiasM
     the only place where you should keep using SLV is at the top level -
     because post fitting timing simulation is loosing the port type -
     and then your testbench doesn't work anymore :(
07/25 23:20:15 bpadalino
     :(
07/25 23:21:16 hiyuh
     MatthiasM: (1) is same b/c think that crappy code like,
07/25 23:21:21 hiyuh
     signal a : signed; signal b : signed; signal c : signed;
     ... some line of code ... c <= signed(std_logic_vector(a)) +
     unsigned(std_logic_vector(b)); -- (3)
07/25 23:21:39 bpadalino
     hiyuh, if you want to shoot yourself in the foot easier, i think
     aliases might make your life more hellish
07/25 23:22:03 MatthiasM
     hiyuh: if I would have to review your code and it contains such a
     thing - you would rewrite it again
07/25 23:27:21 hiyuh
     bpadalino: if you declare port as signed/unsigned, it doesn't force
     to use that type. b/c there is idiot casts.
07/25 23:27:48 bpadalino
     hiyuh, like i said - you can always be an idiot, numeric_std just
     makes it harder
07/25 23:28:42 hiyuh
     and it does also analyze harder. that's why I hate numeric_std.
07/25 23:30:19 hiyuh
     if declaration can not force proper type use, i think type in
     declaration is redundant info.
07/25 23:31:24 hiyuh
     if using numeric_std doesn't allow any casting, it make sense.
07/25 23:31:36 hiyuh
     but it's not.
07/25 23:32:04 MatthiasM
     hiyuh: well - do what you want - but spot anoyng everyone with your
     bad design
07/25 23:32:11 MatthiasM
     *stop
07/25 23:34:27 hiyuh
     annoy?
07/25 23:34:29 hiyuh
     I'm really talking in technical view.
07/25 23:34:31 bpadalino
     you know, no reason to even use std_logic_vectors since we're just
     going down to bits ...
07/25 23:34:37 bpadalino
     so lets just do std_logic
07/25 23:35:52 bpadalino
     hiyuh, you want to be stuck in a type you can't get out of ?
07/25 23:36:05 bpadalino
     or would you rather be forced to think about the computation you're
     doing ?
07/25 23:46:51 hiyuh
     well. you're talking about bit to std_logic migration?
07/25 23:47:12 hiyuh
     you mean it's same wrt migration std_logic_arith to numeric_std?
07/25 23:48:09 hiyuh
     btw sorry for my bad english.
07/25 23:48:51 bpadalino
     i am saying you can use whatever you like - but your arguments
     are weak
07/25 23:49:07 hiyuh
     hmm
07/25 23:50:02 hiyuh
     maybe, it's b/c i have little experience w/ numeric_std.
07/25 23:50:50 hiyuh
     so I should read more elegant std_logic_arith to numeric_std
     migration examples.
07/25 23:51:08 bpadalino
     there's nothing elegant about it
07/25 23:51:26 hiyuh
     why?
07/25 23:51:51 bpadalino
     the way you're doing it, trust me - there's no elegant way about it
07/25 23:51:59 bpadalino
     all your base types are slv ..
07/25 23:52:06 bpadalino
     so you will have to cast everything
07/25 23:52:20 bpadalino
     first to get to something workable, then back to your slv base type
07/25 23:52:35 bpadalino
     you're really doing a lot of work to lose intent and context of
     the code
07/25 23:52:54 bpadalino
     lets write a c program where all we use are char's .. and cast
     everything when we need it to be something else
07/25 23:53:11 hiyuh
     nope, I cloned my proj for the migration test. I'm using mercurial.
07/25 23:53:43 bpadalino
     scm has nothing to do with elegance or porting poorly written code
     to using numeric_std
07/25 23:59:17 hiyuh
     well, I've just done to migrate std_logic_arith to numeric_std
     already.
07/26 00:00:14 hiyuh
     it takes about 1 hour or so. but i think it's ugly.
07/26 00:01:55 hiyuh
     to motivate myself more, I'm talking here.
07/26 00:02:54 hiyuh
     I beleive my code base is not poor you think.
07/26 00:02:57 hiyuh
     it works w/ 2 boards which each one has 4 virtex4.
07/26 00:03:08 hiyuh
     all ones are written in two-process method.
07/26 00:08:03 bpadalino
     sounds great when you're the only person working on the code
07/26 00:08:04 bpadalino
     keep it up
07/26 00:10:08 hiyuh
     yup, it was coded by me only.
07/26 00:29:23 bpadalino
     if you're the only person, write it any way you want
07/26 00:34:19 hiyuh
     ok, thank you for taking your time.

取り敢えず，再確認出来た事としては技術的な話をしている時に"stop annoying"とか"trust me"とかふざけた事を言う奴の意見は聴くに値しないと言う事だな．
結局，suckless.orgのstyle guideが言う様にconsistencyが重要だとすれば，自分のstyleと相容れないpackageを無理に使う事はないって事になるのかな？
つー訳で，やっぱり私は当分の間はnumeric_stdにmigrateする事はありません． :P