Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: rickman Newsgroups: comp.lang.forth Subject: Re: embedded forth Date: Tue, 7 Feb 2017 21:59:44 -0500 Organization: A noiseless patient Spider Lines: 155 Message-ID: References: <49b3566a-3842-4f9f-a47f-a66590625fef@googlegroups.com> <2017Jan23.100126@mips.complang.tuwien.ac.at> <423bc49f-f47d-415d-80d6-53fb0472c929@googlegroups.com> <7f7415ad-9ba0-4d9a-ba9d-d08fad5c344e@googlegroups.com> <92d07db1-18b7-410e-a77c-d7ab4f6606d8@googlegroups.com> <4b343d40-7252-4919-8e0d-aeace01a87cd@googlegroups.com> <5feb22db-9f9c-46df-bdc8-9ae4e14d275d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 8 Feb 2017 02:57:59 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="cd6920b229c8b78398c4bdf504224a30"; logging-data="30002"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19yAfoUAvoOphvAqkNuiLq4" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: Cancel-Lock: sha1:l16cMm3UieNPedKSXCZBO9vOAhg= Xref: csiph.com comp.lang.forth:54699 On 2/5/2017 4:08 PM, rickman wrote: > On 2/4/2017 8:54 PM, Ilya Tarasov wrote: >>> You mean I don't have a fully coded VHDL example at 32 bits word >>> width to show you? No, I don't. But that is not needed. The >>> control logic would be trivial compared to thousands of LUTs. The >>> only extra logic required is on the order of a handful of adders >>> and/or multiplexers. >> >> So you can't show me a code and utilization report, but still >> claiming area will be small? How small? What about 'only extra logic' >> and how you can estimate the size of adders/multiplexers for you >> code? > > I don't need a weatherman to know which way the wind blows. > > I don't have to construct a design to have an estimate of how large it > will be. If I need a look up table with a 10 bit address and 32 bit > words, I know that will take two 16 kbit blocks of memory. If my design > needs 5 - 32 bit adders, I know that will be about 160 - 4 input LUTs. > If the design does a 32x32 bit multiply I know it will take 4 - 18 bit > multipliers and 64 LUTs of adder (if it's using all 64 output bits > otherwise fewer adder LUTs), etc., etc., etc... > > >>> I took the time to do some calculations which show to get results >>> accurate to all but the last bit of a 32 bit word would require a >>> sin() table with a quarter of a million values. That would put it >>> outside the realm of most FPGAs and require external memory. >>> However if external memory is used, this is not only feasible but >>> simple. The only issue is to get the step sizes small enough so >>> the two approximations do apply, sin(b)=b and cos(b)=1.0 to within >>> the required accuracy. >> >> Again, I don't see you 'required accuracy'. Can you list your results >> and explain how you got it? > > How about a Forth program. Good thing I wrote this. I see I made an > error in my manual calculations. This program shows a need for a 16 bit > address in the LUT, not 18. Here is the code. > > > \ calculates the number of bits needed to address the LUT > \ in a DDS for a given number of output bits > \ To preserve the assumption that COS(b) is ~= 1.0 the minimum step of > \ COS in the LUT should be no more than one lsb. > \ FPI/2 is not ANS standard, you may need to add it to your system. > > MARKER SINE > > : 2^F ( f1 -- f2 ) \ Raise 2 to a power, floating point > 2.0e0 FLN F* FEXP ; > > : SinLUTSize ( n1 -- n2 ) \ n1 is number of bits out, n2 is LUT address > bits > DUP S>F 2^F 1.0e0 FSWAP F/ \ Turn bit count into resolution > CR ." Required resolution " . ." bits or " FDUP F. > 1.0e0 FSWAP F- FACOS FPI/2 F/ \ Resolution to phase angle step in 90 > deg LUT > CR ." Maximum phase angle step size in LUT " FDUP F. > 1.0e0 FSWAP F/ FLN 2.0e0 FLN F/ > 0.5e0 F+ F>S \ round to integer > CR ." Number of bits required in LUT address " DUP . > DUP S>F 2^F 1.0e0 FSWAP F/ FPI/2 F* FCOS 1.0e0 FSWAP F- > CR ." Resolution with " . ." bit address " FDUP F. > 1.0e0 FSWAP F/ > CR ." Accuracy of 1 part in " FDUP F. ." or " FLN 2.0E0 FLN F/ F. ." > bits" > ; > > PRECISION 11 SET-PRECISION > > 32 SinLUTSize > > SET-PRECISION > > > > ****** results ****** > FLOAD 'C:\Arius\Projects\Forth\SinLUTSize.f' > Required resolution 32 bits or .00000000023 > Maximum phase angle step size in LUT .00001373774 > Number of bits required in LUT address 16 > Resolution with 16 bit address .00000000029 > Accuracy of 1 part in 3481368790.7 or 31.697007505 bits ok > > >>> I've never seen an application that needed 32 bits of sin/cos. The >>> DDS work I've done was related to real world signals which are >>> limited to some 20 to 24 bits of SNR when converting between analog >>> and digital at very best. I was pretty happy when I showed myself >>> I could get 20 bits without any real trouble. >> >> The fact you don't need it is not a fact nobody need it. ADC >> resolution matters, but this is not the only factor to choose sin/cos >> resolution. Results with single precision and double-precision floats >> are not the same for given ADC. Again, I can write a piece of Forth >> code to show the difference... but maybe you will switch from >> thinking to coding? > > I'm not sure what you are saying here. Single precision floats use > either 24 or 25 bits of mantissa (with 1 bit hidden), I can't recall > which. Either one is as good or better than the cutting edge of any ADC > technology I am aware of with the exception of very high resolution, > very low speed ADCs used for weight scales and such. > > What are you using 32 bit sine calculations for? > > As for thinking vs. coding, I'll take an ounce of thinking for a pound > of coding any day. > > >>>> I have several designs. Now it is 7th generation of >>>> microarchitecture, with hardware multithreading, targeting >>>> Spartan-6 and 7-series Xilinx FPGAs. >>> >>> But that doesn't tell me what a Forth CPU is. I assume you really >>> mean a stack machine. When you say "hardware multithreading", I >>> expect this is using the pipeline to facilitate multiple threads >>> rather than concurrent instructions in a single thread? >> >> Yes, I really mean a stack machine, i.e. words like DUP DROP + - AND >> OR are executed in one clock cycle with all appropriate modifications >> to stack pointers etc. Multiple threads are supported by time >> multiplexing, so one data memory and one ALU are shared between all >> threads, but each clock cycle belongs to its own thread. > > Ok, I just wanted to be clear. I am familiar with the requirements of > stack machines and have designed my own. I believe the multi-threading > you refer to is implemented by using each stage in your pipeline for > separate threads. An 8 stage pipeline allows 8 threads. Often this can > be done without an appreciable lowering of the clock speed compared to a > single thread machine. It does limit one feature in CPUs, low power by > stopping the clock. All thread processors run until all threads are > idle. Only then can the clock be disabled. But no biggie. LOL... I was discussing this in another group and I had completely forgotten what I learned about this when I did the same exercise a couple/few years ago. The determinant of the resolution is the approximation cos(b) = 1.0. In the region of zero degrees the cosine function approaches a quadratic. The slope of the curve is -x^2. So changing the required resolution by two bits requires one extra address bit. The LUT address bits will *always* be half the total phase word bits for optimum accuracy. I can't believe I forgot that. Also, the accuracy will be twice what is calculated by the program (half the error). The value out of the sine table is unsigned and a sign bit is added depending on the quadrant indicated by the phase word. So you get an extra bit and twice the accuracy compared to what my program calculated. -- Rick C