Xilinx Adder Subtracter Core (What's Wrong With Xilinx People??!)

I'm trying to build a simple ALU with an adder/subtracter unit and I need both carry and overflow outputs to set the appropriate flags. However, CoreGen (6.3) doesn't let me have both carry and overflow outputs. I really don't understand why.

Xilinx designers should think twice before limiting their users in such a stupid way. Just because you don't see why someone would want both outputs, doesn't mean that somebody won't find an application that may require them. If you think that doesn't make sense, fine; that's what we have warnings for. Warn me that the value of overflow is meaningless for unsigned numbers, but don't prevent me from using it.

For instance, in this case, I don't know whether the user will add/subtract signed or unsigned numbers!!! It's up to them to decide, and then it's up to them to look into the appropriate flag. Except that I can't provide that flag using this core. Now I have to do it manually, which will most likely be less efficient. And then I'll compare it with Altera's LPM, which will of course be more efficient.

Frustrated,

Fred

P.S.

For those that don't believe that this is the case, you can see it for yourself in the following document:

formatting link
(Table

2)
Reply to
juendme
Loading thread data ...

I use ISE-WebPack, so I guess I don't have CoreGen. I'm still just out of the VHDL newbie stage, but if I understand the document's table #2, it doesn't look like CoreGen will build an adder/subtractor that handles _both_ signed and unsigned data. At least I didn't see a "pin" that tells the logic to treat the data as signed or unsigned. If all that's true, it looks like you'll have to roll your own.

-Dave Pollum

Reply to
Dave Pollum

Such pins do exist (see Table 1.; signals A_SIGNED and B_SIGNED), although I have no idea what exactly those signal do (thanks to incomplete documentation). Because if you look into any digital design textbook, you'll see that the adder/subtracter circuit is exactly the same for both signed and unsigned numbers. The only difference is that carry is not an indication of the error in the result for signed numbers, but you need overflow.

And going back to table 2, what are the 2 extra bits in the result (P=Q+2) in rows 2 and 3? Carry and ....? Could it be overflow? But then why isn't P=Q+2 an option when both inputs are signed? Xilinx, thanks for incomplete and confusing documentation!

In contrast, Altera's lpm_add_sub readily provides both carry and overflow outputs. It also provides a parameter to specify whether the numbers are signed or unsigned, and explains what effect that paramter has on the operation of the circuit (it only affects the behavior of the overflow output, nothing else).

Reply to
juendme

You will probably find that the 'Carry' uses the dedicated Carry logic.. it therefore can support only one function. Two support more.. one has to be done in LUT's that makes it harder.

You could build your own by hand coding LUT's... its a bit of a pain but tit can be more optimal than writing A Such pins do exist (see Table 1.; signals A_SIGNED and B_SIGNED),

Reply to
Simon Peacock

In the "Fairchild TT Applications Handbook" I wrote in 1973:

"Adding two numbers of the same sign, or subtracting two numbers of opposite sign might generate a result which cannot be rpresented by a given word length. This is overflow. It must be detected and used to initiate some corrective routine. Overflow occurs when the Carry out of the sign position differs from the carry in to the sign position. OVERFLOW = Cs XOR C(s+1) When the carry into the most significant position is not directly accessable, it can be generated in one of several ways. The simplest is to use the equation: Cs = Ss XOR As XOR Bs, which makes OVERFLOW = Ss XOR As XOR Bs XOR C(s+1)"

Has math changed in the past 32 years ? I bet there are lots of more famous textbooks that offer similar or more detailed descriptions. This stuff has been known for 100+ years...

Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

OK. And have I said anything different? Tell me what I have said wrong? And why can't one core produce both signals, with overflow being meaningless for unsigned numbers?

Reply to
juendme

schrieb im Newsbeitrag news: snipped-for-privacy@z14g2000cwz.googlegroups.com...

yes you said something different.

the best thing for you is if you would really understand why - its easy todo, just make a small addsub with coregen and then look in FPGA editor what primitives are used. you shoud be able to understand then why the coregen works as it works. if you want something else you have to handcraft it.

Antti

Reply to
Antti Lukats

OK. Can someone quote the sentence where I was wrong? I would like to learn.

I know I can implement overflow myself manually. And I do know how to do it. For those who don't read the whole post, I repeat the sentence from my original post: "Now I have to do it manually, which will most likely be less efficient."

Just because I know how to implement something manually doesn't mean it can't be already provided for me. FolIowing the same logic, anyone who knows anything about digital logic knows how to implement the adder/subtracter manually, so why is that core provided? The reason is; because it's more efficient. Xilinx designers can take advantage of internal structure of LUTs/CLBs/routing structure (carry chains),... to produce the most efficient implementation for every FPGA architecture, so that I don't have to study each single architecture, and tweak my design for each one of them. Or am I wrong here?

Why do you guys have to play smart, instead of reading my post (with understanding) and answering my questions, which were:

  1. Why are both carry and overflow not available in all modes? (Altera provides it for their core, so it is obviously possible)
  2. What does the width P=Q+2 mean? And why is the available width (and the availability of overflow) different when only one number is signed, as opposed to both being signed?

Questions I did NOT ask:

  1. How to implement overflow? (I know that; I can read books and use Google).
  2. I also did not complain about "Fairchild TT Applications Handbook", but rather about lack of functionality description in Xilinx documentation. Had Xilinx people done a good job describing the table previously mentioned, i would have had fewer questions.
Reply to
juendme

Actually, there was another question I did ask:

What do signals A_SIGNED and B_SIGNED do? How do they affect the functionality of the core?

Or is this also explained in some Fairchild handbook?

Reply to
juendme

schrieb im Newsbeitrag news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

I DID READ all your posting. And replayed based on that.

if you want to learn, then what I suggested is what you should do, this way I hoped you would learn and understand.

ok, if you dont wanna learn yourself then you well this was already given in an another post to you, the addsub uses carry chain and there just is not 'other' pin available. So you get the result and one additional signal - thats it. If anything else is required it can not be implemented by the addsub carry-chain built macro.

and as of efficiency of the coregen - it is defenetly possible to make as efficient or better (hard)macros by hand, so if you know what you want just implemenet it in efficient way and forget the coregen.

Antti

Reply to
Antti Lukats

The Quartus tools spot many common hand-coded constructs, and implement them with cores automatically, so that writing your addsub by hand or using the ready-made cores will give the same implementation. Won't Xilinx tools do that too?

Reply to
David Brown

Sure the Xilinx flow does the same, but...

if you write some construct that does add and sub and provides __separate__ outputs for carry and borrow, then how should that be written in order to be recognized for core extraction and what should the coregen actually implement?

For 'normal' addsub there are no problems. The OP wants carry and borrow at the same time from the same core primitive !

Antti

Reply to
Antti Lukats

My point is that the OP should write the code the way he wants it to run. If the Xilinx tools can implement it using some faster or smaller mechanism than an obvious LUT implementation, then great. If not, then it's likely to be because there is no such better implementation on the particular architecture. But you let the tool do the work, rather than trying to figure out how to force the coregen into making the right construction. That's why we use these tools, rather than drawing out Karnough maps and hand-optimising everything.

Reply to
David Brown

I answered the unfriendly original posting with a constructive suggestion: Use the XOR of four accessible signals, which would fit into a single LUT. Specifying a single LUT doesn't look like a big manual effort to me... Peter Alfke

Reply to
Peter Alfke

"Peter Alfke" schrieb im Newsbeitrag news: snipped-for-privacy@g49g2000cwa.googlegroups.com...

Hi Peter,

yes, you did even more than that in friendly manner to an unfriendly poster!

It can not be expected that some core generator provides all possible cores and options to all the wishes we might have.

If the intent of the OP was to design an efficient ALU then he pretty much needs to look at the FPGA primitives in order to understand what actual hardware resources will be used to implement what he needs.

Antti PS there is nothing wrong with Xilinx people, and Xilinx software(coregen) does in most cases all that is reasonable, if something that 'could be useful' feature is missing there are or could be reasons for that missing feature.

Reply to
Antti Lukats

Dear Mr. Alfke,

Thank you for your constructive suggestion. However, after 15 posts on this thread, I only got philosphical opinions, and answers to questions I did not ask. I still didn't get my questions answered. I repeat them again:

What does the width P=Q+2 mean? And why is the available width (and the availability of overflow) different when only one number is signed, as opposed to both numbers being signed?

What do signals A_SIGNED and B_SIGNED do? How do they affect the functionality of the core?

IMHO, answers to these questions should be an integral part of the Adder/Subtracter specification referenced above. If you can show me that these questions are already answered in the specification, I will take back whatever I said.

In the meantime, I still stick to my original question: What's wrong with Xilinx people?

Cheers,

Fred

Reply to
juendme

Fred,

formatting link

I invite everyone to read the pdf describing the core.

Especially pages 2, 3 and 4.

Doesn't seem to be any mysteries here (to me).

For example, it clearly states that if the result of the operation will generate a signed result (because one or both of the operands is signed), then signs are then automatically included....

P and Q are defined on page 3 in Figure 1, note 1.

Perhaps "what is wrong with Xilinx people" is that we do not understand what it is you are asking.

Aust> Dear Mr. Alfke,

Reply to
Austin Lesea

Actually there is something which can be quite confusing to the uninitiated in that document. In at least two places the "Output width" refers one to "Table 2" for specification (one of the referals is in table 2 itself on page 6, the other is on output width description page 3). These referals should say "Figure 1" instead. I think someone should review that document for accuracy.

Reply to
m

Antti Lukats schrieb:

Maybe it could be implemented the way Peter suggested? With a single LUT?

Kolja Sulimma

Reply to
Kolja Sulimma

MK,

Thanks, I can refer this back to the document folks to look into.

Aust> >

Reply to
Austin Lesea

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.