EDK : FSL macros defined by Xilinx are wrong

[Leow Yuan Yeow]

Hi, for a program such as
case state is
when S0=>
A <= B + C;
when S1=>
Z <= X + Y;
does it mean that 2 adders are generated, or will the synthesis recognize
the adder can be shared?
Or to I have to specifically write a multiplexor for the adder? Thanks!


"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:480fvpFhqii0U1@individual.net...

Leow Yuan Yeow wrote:
Does resource sharing also apply for a + sign in different states? It
appears the synthesizer doesn't like my code then.

If you want to share an adder,
it is best to describe exactly how in your code.

Resource sharing by synthesis requires
duplicated descriptions or a selection
that can be made either by muxing
inputs or outputs, like this:

if op1 then
q_v := A + B;
else
q_v := C + D;
end if;

I might duplicate a register description by mistake and
be happy about a silent band-aid from synthesis.
Or I might prefer just a warning so I can clean up my code.
Then again, I might duplicate a register just to buffer the signal
and prefer that synthesis keeps hands off.


-- Mike Treseler

 

[Aurelian Lazarut]

Hi John,

"Not discussed was a proposal that the FPGA vendor could provide maybe
subquadrant level defect bin sorting .... which could be transmitted
via markings on the package, or by order selection, or even by using 4
balls on the package to specify the subquadrant."

This is not a new idea, to bin them on a quadrant basis, the catch
about this is more complicated than it looks.
In order to bin them you need to identify the defect with much higher
accuracy than normal testing, you want to know the position (that's easy
) and the nature of the defect, because not all defects will map nicely
to this method, try to imagine a defect on the global routing net, this
will can disable more than one quadrant, or a IO defect on a device with
an IO ring (old devices) or an interruption on a long line which has
cross from one quadrant to another, what about a defect DCM ? the defect
map becomes quite complicated, but this is only the tip of the iceberg.
In order to qualify such a part the time spent on a tester will be an x
fold, not to mention the engineering effort to find out more about a
particular defect ($$$) just to end up with a part which is "limping".
In all this time spent on the tester you could test x times more parts
(good ones) that we can sell as OK, and use engineering time to improve
the coverage for testing.(not to mention the burden of managing parts
with different quadrants which becomes a new part from the logistical
point a view, marking packing, storing etc.)

Aurash

PS.
I apologize for my English I'm not a native speaker/writer.

 

You don't need an extra interrupt controller if you connect two devices
as you described.
However, two interrupts will have different priority, and the critical
interrupt (interrupt from critical interrupt port) will interrupt the
external interrupt (interrupt from external interrupt port), and so if
you don't write your interrupt handler code carefully, you may face
some weird behaviors.

Sewook Wee

 

[Ray Andraka]

Sylvain Munaut <SomeOne@SomeDomain.com> wrote:

Hello,

We're currently working on a design running on a Virtex4 SX35. That
design uses most of the resources of the FPGA (around 80% of the slices
and 50% or the BRAMs/multipliers). We're working on the AVNET SX35 kit
with a VGA extension card and a sdram expension card.

Depending of the datafiles we send, sometimes it completly deconfigure
the FPGA ... done goes de-asserted and nothing is processing anymore
...
But that behavior is not deterministric, sometimes it can process for
one minute and then deconfigure, or sometimes it just can't even
process 1 second without crashing ... Apparently the more "heavy" is
the datastream, then faster it will crash.

Anyone would have an idea of what's going on there ?


Sylvain

Sounds like your design may be drawing more current than the the power

supplies can provide. YOu might try monitoring the FPGA supply voltages.

 

[Brian Davis]

Pablo Bleyer Kocik wrote:

I am having a bit of trouble intercepting the adder carry in a carry
chain with ISE using behavioral code. I am currently using two muxed
adders (one 8-bit, one 16-bit) for the addsub module instead of the
ideal high/low 8-bit adders with full and half carries. Any ideas on
how to implement this in ISE?

I think you'll need to code dummy bits at the middle and top of
the adder to pull out the carries.

Here are some old posts with structural (Xilinx) and RTL versions:
http://groups.google.com/group/comp.lang.vhdl/msg/51a0b827ee12f69c
http://groups.google.com/group/comp.lang.vhdl/msg/15ad1c9b11079f7a
http://groups.google.com/group/comp.arch.fpga/msg/622e2173af20bb16

IIRC, using two dummy bits at the top ( '0' & copy_of_sign_bit ) makes
coding synthesizable RTL signed/unsigned carry/borrow/overflow flags
easy to implement, but quickly googling didn't turn up the post that I
recall which explained that technique.

Brian

 

[Isaac Bosompem]

Ray Andraka wrote:

Sylvain Munaut <SomeOne@SomeDomain.com> wrote:

Hello,

We're currently working on a design running on a Virtex4 SX35. That
design uses most of the resources of the FPGA (around 80% of the slices
and 50% or the BRAMs/multipliers). We're working on the AVNET SX35 kit
with a VGA extension card and a sdram expension card.

Depending of the datafiles we send, sometimes it completly deconfigure
the FPGA ... done goes de-asserted and nothing is processing anymore
...
But that behavior is not deterministric, sometimes it can process for
one minute and then deconfigure, or sometimes it just can't even
process 1 second without crashing ... Apparently the more "heavy" is
the datastream, then faster it will crash.

Anyone would have an idea of what's going on there ?


Sylvain

Sounds like your design may be drawing more current than the the power
supplies can provide. YOu might try monitoring the FPGA supply voltages.

I was thinking along similar lines as well.

-Isaac

 

[Phil Hays]

John Bass fpga_toys@yahoo.com wrote:

With a systems guy view, I can only wonder why die level and package
level ATE is required.

Why test at die level at all? Economics. Packaging costs money.
Why test at package level at all? Full testing at wafer sort isn't
realistic, and die damage during packaging happens.

Design for test has to be one of the most
critical requirements in the process - from die to system. It would
seem that the the ATE function should probably be redundant on the
wafer at fab, tightly integrated to the application die's IO pads --
AND critical internal logic not visible from pads. The wafer in this
environment would have surface metalization on one edge for power and a
network interface. The ATE function on the wafer would include power
control for each die, an on wafer jtag chain, plus an on wafer gigabit
network, each bused to a set of pads on one keyed edge of the wafer.

Something quite like this was tried. Some very good reasons not to do
it were found, the hard way. "Human beings, who are almost unique in
having the ability to learn from the experience of others, are also
remarkable for their apparent disinclination to do so." (Douglas
Adams)

There is nothing special about the ATE's test interfaces, that can not
be implemented on wafer with some good test for design strategies.

Power supply measurement requires an ammeter per power supply per die,
or some way to switch an ammeter between measurement points, like
relays. I'd love to hear your plan.

Some things can't be implemented on wafers. Disk drives, relays,
precision resisters, ...


--
Phil Hays

 

Phil Hays wrote:

Why test at die level at all? Economics. Packaging costs money.
Why test at package level at all? Full testing at wafer sort isn't
realistic, and die damage during packaging happens.

And for some, such a damn if you do, and damn if you don't is a
purfectly good excuse to do nothing. Life isn't purfect. Finding
solutions I find more valuable than finding restrctions and excuses.

Something quite like this was tried. Some very good reasons not to do
it were found, the hard way. "Human beings, who are almost unique in
having the ability to learn from the experience of others, are also
remarkable for their apparent disinclination to do so." (Douglas
Adams)

One of the most remarkable forms of success, is the difficult
challenges offered from failures. The cost of chipping away at this
problem could be relatively small, one or two engineers for a few years
adding a very small complexity addition to production die. When success
materializes, the savings are substantial.

Power supply measurement requires an ammeter per power supply per die,
or some way to switch an ammeter between measurement points, like
relays. I'd love to hear your plan.

It always comes down to V=IR and there are plenty of designs/products
that do current sensing well, even if an external reference standard is
required. Maybe one of the ATE functions is to calibrate on die
standards, and pass that to the rack manager.

Some things can't be implemented on wafers. Disk drives, relays,
precision resisters, ...

None of which are needed on die for self testing.

 

[Morten Leikvoll]

Btw.. I should tell you how I know its the xst doing this:
I look at the post-synthesis simulation model..

 

fpga_toys@yahoo.com wrote:

I'm willing to invest the engineering into developing a
recovery process, if Xilinx is willing to provide scrap material, and
include in that partnership an agreement to share data and design
suggestions to improve yeilds. As the recovery process becomes
profitable, there is certainly incentives on both parties part to share
that windfall. That's a pretty low risk deal for Xilinx if they are
crushing scrap in die and packaged form today.

I'm willing to consider the same for other FPGA vendors as well.

 

[Brannon]

I posted on here a few hours ago but haven't seen the response so I'll
try again. My theory is that if you are relying on the mapper to swap
out TBUFs for logic, that somehow messes with the register removal. I
think this option has some issues anyway; using it you think you're
optimizing when really you're shooting yourself in the foot because it
doesn't leave enough registers for the IOBs. I'm just grateful Xilinx
is finally starting to migrate the optimization to the mapper state --
the place where things like IOB register needs can be considered.

 

Jim Granville wrote:

Sounds simple - become an EasyPath customer!

It's the NRE and volume commitment that are the real OUCH.

I'm glad that the $5-10M is pocket change for your business.

 

fpga_toys@yahoo.com wrote:

It's the NRE and volume commitment that are the real OUCH.

Hmmm ... I thought I saw a statement there was a 10,000 min for the
program, which I don't see any more .... might not be as big a hit.

 

[Ray Andraka]

John,

I'm not saying your ideas won't work, I am saying that you have a very
large task ahead of you, perhaps larger than you realize. I'd like to
see you pull it off, as doing so would mean that you've solved a number
of vexing problems that have plagued the RC community for a long time. A
solution to many of those problems would also greatly benefit the
designers of static designs as well.

So far, however, your posts have pretty much focused on whining about
what you can't get rather than on solutions to the known problems.
There is a tremendous amount of FPGA experience and knowledge among
people on this newsgroup. I believe many of us have tried to point out
the pitfalls (that many of us have already encountered) so that you
might have an easier time navigating the field. Your responses so far
have mostly been whining about what you can't get rather than looking at
ways to get around those obstacles within the framework of what is
available. Posting it here and not listening to the advice the seasoned
veterans here have offered only serves to sour people on your ideas. If
you truely feel you've discovered a route to success that others who've
been playing in this field for over a decade have not seen, then it
would make sense for you to first get patent protection for your ideas,
and then go into Xilinx and other FPGA vendors and negotiate with them
for what you want. If you have a convincing story, I suspect they'd be
asking you what you need rather than the other way around. If you can
solve the fast PAR issues, for example, you could probably fund your
development with the proceeds from the FPGA companies lining up at your
door to buy rights to your PAR algorithms.

I respectfully suggest you try first to get the system together
using perfect FPGAs,

When I referred to the system, I am not just talking about the FPGA
boards. That's the easy part. I am referring to the implementation
tools, libraries, user interfaces etc. Many of the major pieces you need
are still a long way from being developed enough to be usable in a
general purpose RC system such as you have described.

 

Ray Andraka wrote:

Your responses so far
have mostly been whining about what you can't get rather than looking at
ways to get around those obstacles within the framework of what is
available. Posting it here and not listening to the advice the seasoned
veterans here have offered only serves to sour people on your ideas.

The responses so far have been far from advise, they have been the
stock answer that it's been tried before and fails. Advise to fail by
failing to try.

Advise is suggestions on how to move past prior failures, and get past
the limitations of the existing tools.

 

[radarman]

J Silverman wrote:

Hi All,

Ok, you all kinda convinced me on this. After three days of searching for support software and not finding any, I started looking for another way of using a more modern FPGA. I was originally looking at the original Spartan (as they came in PLCC84 packaging) but cannot find any for sale in small quantities. So I started looking for ways on how to use a current FPGA in a breadboard, and I came across this site:

http://www.beldynsys.com/quadpacks.htm

They have a bunch of boards that will take SMT components and give you the ability to stick them in a breadboard. I was looking at the Q100-80 one and am wondering if that will work for a Spartan3 in VQ100 packaging. I'm not sure if the difference between VTQFP and TQFP is great enough to cause problems when trying to solder it on the board.

Thanks, J Silverman

You know, it's really a shame that there aren't more minimal
"breadboard" adapters for FPGA's. The Xilinx sample pack was darn
close, but had an odd shape, and not enough grounds. (that didn't stop
me from mounting the peripheral connectors on the other side, and
plugging it into a breadboard) Opal Kelly makes a decent "breadboard"
style part, but it's $200 - does come with some nice software drivers,
though. XESS also makes some breadboardable products as well.

The real problem is that you practically have to have a PCB with fairly
controlled trace lengths and properties to get modern bits working. The
days of wire-wrap are virtually over, except for low-speed and
non-critical analog.

Keep in mind, even if you do manage to get a modern part on a
breadboard or protoboard, you still have to power it. There are plenty
of linear regulators to do the job, but virtually all of them are SMT
(and flyspecks to top it off)

It is a shame, though. I have some of those older parts in my drawer,
and I hate to throw them out as well - even though I know I'll never
build anything with a Xilinx XC3042...

 

[Ray Andraka]

radarman wrote:

It is a shame, though. I have some of those older parts in my drawer,
and I hate to throw them out as well - even though I know I'll never
build anything with a Xilinx XC3042...

Put them on ebay. Somebody might be able to use them for an existing

product, provided they are still in the packaging.

 

[Ray Andraka]

Virtex4 uses RAMB16 instead of RAMB16_Sxx_Sxx. It is more convenient
for parameterized blocks. A little bit more awkward for straight
instancing. Pay attention to the addressing for different sizes, it may
not be intuitive.

 

[Peter Alfke]

The simplest solution is to make the whole asynchronous FIFO 16-bit
wide, and build a simple synchronous "pre-assembler" that composes a
16-bit input from two successive 8-bit inputs. CoreGen does the rest
for you.

Peter Alfke, Xilinx (from home)

 

[Jdon]

Thanks.

But the problem of the asynch-FIFO 16 is that
I couldn't prevent simultaneous read and write.
When the process tries to read and write at the same time by chance,
the output is distorted.

How could I prevent this?

"Peter Alfke" <alfke@sbcglobal.net> wrote in message
news:1143007400.912744.78060@i39g2000cwa.googlegroups.com...

The simplest solution is to make the whole asynchronous FIFO 16-bit
wide, and build a simple synchronous "pre-assembler" that composes a
16-bit input from two successive 8-bit inputs. CoreGen does the rest
for you.

Peter Alfke, Xilinx (from home)