Prev: xc3sprog
Next: USB programmable Open Source Hardware
From: Andy on 22 Sep 2009 19:34 On Sep 22, 7:27 am, KJ <kkjenni...(a)sbcglobal.net> wrote: > On Sep 22, 7:18 am, Antti <antti.luk...(a)googlemail.com> wrote: > > > signal next : integer range -1 to 2; > > I missed this line in my first post. So for starters, 'next' would > have to be 3 bits based on the defined range. As I mentioned in the > previous post, depending on what the logic actually is, some of the > bits could be optomized away during synthesis. If there is a two bit > (or one bit) implementation, synthesis tools will most likely find > it. Reduction of simple boolean logic as in this case is their strong > suit. > > Kevin Jennings Most synthesis tools implement symmetrical signed ranges, so -1 to 2 takes the same number of bits as required for -3 to 2, which is 3 bits. Most synthesis tools will implement "integer range 6 to 7" as three bits too (same as for 0 to 7). Most synthesis tools will not alter the coding to use fewer bits. Synthesis might be able to optimize decoding the value based on the range specification (i.e. values -2 and -3, while representable in three bits, are not, by definition, possible), such that decoding, e.g. 2, only requires looking at two of the bits, etc. Andy
From: KJ on 22 Sep 2009 20:27 On Sep 22, 7:34 pm, Andy <jonesa...(a)comcast.net> wrote: > On Sep 22, 7:27 am, KJ <kkjenni...(a)sbcglobal.net> wrote: > > Most synthesis tools will implement "integer range 6 to 7" as three > bits too (same as for 0 to 7). > > Most synthesis tools will not alter the coding to use fewer bits. > That's only one of the first steps in the synthesis process though. Synthesis tools will then look at the boolean logic that gets created and optomize that. As I mentioned previously, the OP's example where the only assignment was to a value of -1 (because he intentionally commented out the rest for clarity) would cause 'next' to get reduced to a constant which would then get absorbed into whatever logic that depends on 'next' so 'next' would be implemented in 0 bits. Another example would be if the only use of some integer that is defined to be in the range of 0 to 7 is of the form "if my_integer >= 4 then..." would result in only one bit being implemented...this would also be true if the range was define to be 4 to 7 or -529 to 683. The bottom line is one can't really answer the question of how many bits it will take to implement some integer without knowing the context of how that integer gets used (i.e. what is the logic that uses that integer). Knowing the defined range for the integer tells you the upper bound on how many bits it might take, not the actual number. Kevin Jennings
From: KJ on 22 Sep 2009 20:53 On Sep 22, 8:27 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: Disregard this part.. > this would if the range was ... or -529 to 683. >
From: Andy on 23 Sep 2009 09:07 I see what you are getting at, and you are correct, to a point. Yes, if it turns out that none of the bits is ever used, then none of the bits will get implemented (we have no idea where/if "next" gets used). However if it is used, the coding, or those bits that are left of it, in all the synthesis tools I have seen, will be from the original three bit encoding. For example, I have yet to see a synthesis tool that would recode range -1 to 2 as range 0 to 3, which would allow ALL valid values to be encoded with only two bits. > Another example would be if the only use of some integer that is > defined to be in the range of 0 to 7 is of the form "if my_integer >= > 4 then..." would result in only one bit being implemented...this would > also be true if the range was define to be 4 to 7 ... Actually, decoding "my_integer >= 4" from a value with a valid range of 4 to 7 could take zero bits (constant TRUE). Synthesis sometimes (I haven't nailed down exactly under what conditions) looks at what gets stored in an object as well as what is read from it to make optimizations. I have seen this occur with a counter that counted from 0 to 5 and rolled over, unconditionally. It happened to be a natural range 0 to 5. I don't know whether Symplify took the range as a hint, or performed a reachability analysis on the counter, but it only looked at two of the bits to decode some of the values. Andy
From: gabor on 23 Sep 2009 11:06
On Sep 23, 9:07 am, Andy <jonesa...(a)comcast.net> wrote: > I see what you are getting at, and you are correct, to a point. Yes, > if it turns out that none of the bits is ever used, then none of the > bits will get implemented (we have no idea where/if "next" gets used). > > However if it is used, the coding, or those bits that are left of it, > in all the synthesis tools I have seen, will be from the original > three bit encoding. For example, I have yet to see a synthesis tool > that would recode range -1 to 2 as range 0 to 3, which would allow ALL > valid values to be encoded with only two bits. > [snip] > > Andy It turns out that even with simple binary encoding, the values -1 to 2 (or any set of four contiguous integer values) can always be decoded using only bits 1 and 0 as these are different for each value. In the case of -1 to 2 they are 11 00 01 10, and so even though bit 2 also changes it is not necessary to use bit 2 for decoding IF the optimising agent is smart enough to detect that bit 2 can be described as a function of bits 1 and 0 and is therefore redundant. Regards, Gabor |