pROM = genROM(&fsckin_IO_rel);

#vhdlにて。
[At #vhdl.]

05/09 20:38:20 _vanpelt
    hi, i have to convert an 7bit input signal to another output
    signal. the converting table is very large. is it better to query
    an array or to write a very long "when" statement?
05/09 20:48:26 hiyuh
    input synchronously, covert it synchronously, output
    synchronously... this is common way to function w/ faster0rz clock
    but input-to-output latency is large.
05/09 20:48:36 hiyuh
    asynchronously convert directly input to output is shortest
    input-to-output latency, but it won't function w/ faster0rz clock.
05/09 20:48:51 hiyuh
    so it's up to you.
05/09 20:49:06 _vanpelt
    the whole architecture is asynchronous
05/09 20:50:37 hiyuh
    if you intended to make it to be asynchronously w/o paticular reason,
    then I'd have to say it's bad design.
05/09 20:51:23 _vanpelt
    hiyuh: i have to implement it after a given design :) no possibility
    to make it synchron
05/09 20:54:36 hiyuh
    wtf :p
05/09 21:10:14 _vanpelt
    hiyuh: its from my university :)
05/09 21:11:33 _vanpelt
    hiyuh: but theoretically it makes no difference whether to query
    an array or a waste when list am i right? because the number of
    comparations is equal?
05/09 21:14:41 hiyuh
    nah, it depends what signal will be inputed, how signal will
    be converted, what signal will be outputed, and what device and
    synthesizer are you using. :p
05/09 21:15:37 _vanpelt
    hiyuh: i don't need any synthesizers or devices. it is for simulation
    only
05/09 21:16:26 _vanpelt
    hiyuh: or to ask the other way, what is more elegant?
05/09 21:20:59 hiyuh
    IMHO, how signal will be converted is really complex and looks like
    randomly, pre-generated constant array to output by input signal
    indexing is what I'd code.
05/09 21:21:42 hiyuh
    the array will be generated by TSV and/or SSV (maybe I'll generate
    it by using some program or its spec) w/ awk(1p) and/or sed(1p) script
05/09 21:23:15 hiyuh
    how signal will be converted is simple or semantical, just code
    function. then use it like, "output <= MyAwesomeFunction(input);"
05/09 21:23:16 _vanpelt
    how do you mean input signal indexing?
05/09 21:24:18 hiyuh
    output <= MyAwesomeConstantArray(input1 & input2 & input3
    & ... & inputN); <--- this looks like indexing.
05/09 21:25:01 _vanpelt
    hiyuh: ok. but there is no function that is able to actualy
    calculate the value according to input. the numbers in the array
    are to independent
05/09 21:26:09 _vanpelt
    so i could implement binary search or something but i think that
    this would go a step to far, doesn't it?
05/09 21:27:39 _vanpelt
    the problem is that there is no function that could calculate the
    position of the result from the input value
05/09 21:28:37 hiyuh
    eh?
05/09 21:28:49 hiyuh
    so I'd have to say no idea.
05/09 21:28:50 hiyuh
    I haven't seen desired I/O logical relation what you're talking about.
05/09 21:29:19 hiyuh
    I'm moronic coder, no code (or spec) is no help.
05/09 21:31:16 _vanpelt
    hiyuh: ok sorry for being so imprecise. the input vales range from
    1500 to 300. but not every value is needed. for example only 1500,
    1463,1428,...
05/09 21:31:35 hiyuh
    ok, then?
05/09 21:31:59 _vanpelt
    but the output values are constantly increasing 40,41,...
05/09 21:32:48 _vanpelt
    so what i have to do is asigning 1500 -> 40, 1463 -> 41,...
05/09 21:34:39 hiyuh
    heh, so you have that entire of fsckin' I/O relation already?
05/09 21:35:23 _vanpelt
    yes i have a table on paper for this huge list
05/09 21:38:42 hiyuh
    ok, then generate constant ROM declaration from that fsckin' list
    into package vhdl by hand or script or something.
05/09 21:38:43 hiyuh
    then use it like "output <= MyAwesomeConstantROM(input);" w/
    "use work.MyAwesomeConstantROM.all;"
05/09 21:40:14 _vanpelt
    wouldn't that produce overhead because then i would have to generate
    an array of 1500 elements and use only 300 of them
05/09 21:41:44 _vanpelt
    because i could asign the input values the position of the output
    values in the array, search in the array for the right input value
    and return the position
05/09 21:44:42 _vanpelt
    i really appreciate your patience :)
05/09 21:44:59 hiyuh
    nah, create "input_value output_value" TSV or SSV, sort(1p) it by
    input_value, use script or program to generate constant ROM by using
    dummy stub value (which won't output).
05/09 21:46:30 _vanpelt
    hiyuh: ok i will do it that way. thanks a lot for your help!
05/09 21:46:57 hiyuh
    np, good luck. :p
05/09 21:47:11 _vanpelt
    hiyuh: really great. thanks

05/09 23:57:44 _vanpelt
    hiyuh: i got another, this time hopefully simplier question. i just
    read a vhdl performance manual. is it really true to prefer integers
    over slv's?
05/10 00:02:51 hiyuh
    _vanpelt: performance for what?
05/10 00:02:53 hiyuh
    shorter simulation runtime? shorter synthesizing time? function w/
    faster clock? lower power or current?
05/10 00:03:52 hiyuh
    and wth is vhdl performance manual??? :p
05/10 00:04:07 _vanpelt
    hiyuh: if i have nothing like that specified, which optimization
    should i use? as it is mainly simulated for simulation?
05/10 00:04:51 _vanpelt
    hiyuh: the paper is called "VHDL Style Guidelines for Performance" :)
05/10 00:07:27 hiyuh
    BWK and RP said like that, IIRC. "first of all, to optimize your code,
    don't optimize it."
05/10 00:08:09 _vanpelt
    hiyuh: :) ok
05/10 00:09:27 _vanpelt
    hiyuh: but could i say that using slv's i am closer to the hardware
    and so it is better when synthesizing it or running it on an FPGA
05/10 00:13:09 hiyuh
    for synthesizer, good one can optimize your code w/ runtime options
    than your hand-optimize.
05/10 00:13:17 hiyuh
    but bad one produces ton of craps. :p
05/10 00:15:15 hiyuh
    FYI. for simulation, good one can optimize your code JIT than your
    hand-optimize.
05/10 00:15:19 hiyuh
    but bad one takes so looooooooong time. :p
05/10 00:14:54 _vanpelt
    hiyuh: ok. thanks again. i wont annoy you again today :)

他の言語でも俺様コードジェネレータをでっち上げるのは良くある事だし、最近は王道のスタイルで
書かれたコードをマトモなツールで使えばキチガイの様に手で最適化する必要は殆ど無い。
勿論、VHDLのRTLデザインはハードウェアに突っ込まれるので、I/Oの位置やタイミング制約で
悪足掻きする事はかなりあるけど、それは元のブツが王道のスタイルで書かれている方が弄りやすい。
[Codin' code generator is nice lazy way, that's not only for VHDL. T3h royal road style code w/ suckless tools won't require any of hand-uber-optimization, recently.
Yup, RTL level VHDL is intended to be into the device, so it has many I/O location and its timing restriction. But before poking it for these ton of restriction, original one as royal road design is the best one to start.]

シミュレータは、マトモなモノはそれなりに優秀で、JITな感じで動いているのは見ているだけで
大体分かる。
なので後は、「delta delayが少ないスタイルで書かれているか、否か？」でシミュレーションに
必要な時間が決まるんじゃないかと妄想している。
で、某G社の人が提唱しているスタイルが最強ではないかと思うのだがどうか？ :)
[Recently, simulator becomes suckless a little. I guess it run w/ JIT optimization in my exp.
So, the last curse is "how many delta delaying　is required to simulate it?", IMHO.
Then, t3h G guy sez awesome royal road style, so I was really surprised. :)]