O HAI THIS BLOG PURPZIEZ 2 B UZED AZ MAH PLESIOUS MEM. :)

2008/05/10

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. :)]

0 件のコメント: