EDK : FSL macros defined by Xilinx are wrong

[samiam]

You're about to waste your money, IMNSHO. Especially if you don't already
have a universal programmer that can handle them.

Point taken.
I wont invest in them ... especially after reading through my universal
programmer and NOT seeing them listed.

If they're free, they're too expensive.

Ok

You can buy a brand-shiny-new Xilinx XC9536 in a PLCC for $3.30,

I avoid CPLD's. seriously. I think they are OVERKILL for the stuff I do
and put me wayyyyy above the details I like to fool around with when I
am designing boards

I also hate messing with anything that I can NOT get in DIP form since
I build the boards at home.

Maybe as my exposure and experience designing and building boards at
home improves ... I may get to that point.

But for now I love simple PLD's ... 16R8' 22v10's for replacing 74xx
parts. Nothing more.

 

[Martin Thompson]

Superman <harissh77@yahoo.com> writes:

Hi guys,

Any 1 help me with info on *.XDL file, i know that this file a ASCII
verison of the NCD file. can 1 tell me where i can get more info?? i
have extensively searched the Xilinx webpage in vain.

Create an XDL file of your design and it will have some (all that
exists to my knowledge!) documentation of the format inside.

There was a long thread on XDL not long back, which you might find
enlightening... search google groups for "working with XDL"

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt

 

oh i dont think there is any licensing problem, because so many companies are
allready selling compatible chips on net and also in trade show.. without any
problem..

can anyone help?

thanks


In article <ddQ_f.6732$tT.3171@news01.roc.ny>, John_H says...

Contact HP for licensing information. I believe they are legally required
to make available - for a reasonable price - the chips or the technology for
toner refillers and alternative suppliers. Doing so without their
permission may result in the product you produce violating copyrights or
considered black market.

tonerchips@hotmail.com> wrote in message
news:e1fg5i01hpf@drn.newsguy.com...
hi all
i indent to make chips for toner cartridges ( specially hp ) in singapore
i need technical assistance in this regard and willing to pay reasonable
amount
for technology.
kindly let me know if anyone can help

thanks
tonerchips

--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

 

[Rene Tschaggelar]

It is the free version of the software, the
downloadable license is in place. I'm going
to measure the JTAG signals now.

Rene


chark.chen@gmail.com wrote:

there are many reasons that will make the computer could not find the
cable.
1. If you have the hardware dog ( it is a kind of license), install it
with the cable.
2. Most of time, i just chang the cable, computer or reinstall the
software, and get the good result.
could you describe the details of your condition?

Rene Tschaggelar 写道：


For a legacy project I have MaxPlus2 with the
Byteblaster MV. For a reason unknown to me,
the Programmer modal tells me that the
programmer is not there. "Can't find programming
hardware"

I checked the JTAG pins and their voltage levels.
It should be correct. What else is checked ?

The device connected : EPM3128AT144-10

 

[Lars]

You must install the driver for the cable first. See:
http://www.altera.com/support/software/drivers/dri-bb-2k.html
/Lars

 

[radarman]

As a former senior design project lab instructor, let me give you a few
hints.

1) Make it simple. You don't have time to debug unnecessary crap. I've
seen great projects that would have earned A's had they been completed
- yet get C's because the students bit off more than they could chew,
and got stuck debugging unnecessary problems. This is an important
skill later, as well. Nobody wants to explain that a product will ship
late because some engineers "toy" broke something, and forced a long,
unnecessary, and expensive debugging cycle.

2) If you don't absolutely need it - don't worry about it. That's why I
asked if you really need configurable logic. FPGA's are neat, and in
some cases, invaluable - but if all you are doing is controlling a
serial device and an LCD - unnecessary. They add complexity, and design
time, without offering much in return. On the other hand, they do allow
you to do true system-on-a-chip designs. The S3 or S3E starter kits are
great for this, because they are entirely self-contained. I would
suggest you look at opencores.org. I am using the Plasma MIPS processor
in a design of my own, and you can cross-compile with either Windows or
*nix based compilers. If you have (or can get) the full Xilinx EDK,
Microblaze is a very nice soft processor, and you get a full
development environment.

Keep in mind, an FPGA will present an additional set of design problems
on top of all the others you have. Specifically, you must make sure
your design can make timing, your pin-out must match what is expected
by the rest of the system, and code debugging becomes more complex than
just "recompiling". You now have to generate a new bitstream, and
upload it to the target everytime you make a change. (EDK helps a lot
here)

3) C#, to my knowledge, is limited to a very few platforms, and as a
previous poster noted, none of them are microcontrollers. I'm not
anti-Microsoft, but .net was not intended for embedded computing. If
you can't use a PC (running Windows) as your controller, and must use a
micro, I would use C and/or assembly. It gets the job done, and you can
get free cross compilers to almost any platform known to man. Yes, you
can write C programs targetting Atari 400/800's and Commodore 64's if
that's your thing.

4) If you are planning to graduate this Spring, I would suggest hoofing
it. Debugging always takes an order of magnitude more than the initial
development - no matter how careful you were in the design phase.
Something about Murphy's law I think...

Finally, if you are set on using an FPGA, consider using finite state
machines (FSM) instead of a full processor. You would be amazed at how
much you can accomplish. I've done designs with reasonably complex user
interfaces with little more than an FSM and a ROM. Your application
practically screams for a well-designed FSM.

Remember, software is essentially a FSM executed on another FSM (the
CPU). Any software function, including recursion, can be fully
reproduced in hardware. The opposite is not true.

 

[David Quińones]

Hello Marco & Vladimir

Unfortunately we need TCP/IP in our products, so we need to use the TCP/IP stack and prefereably without any cost. In the relating thing to the speed of transmission on gigabit ethernet, we have reached more than 900 MB/s with the ML403 development board and a cathegory 6 crossover cable with the GSRD reference system, who use the Treck TCP/IP stack with Jumbo frames. Without Jumbo frames the transmission speed falls to 250 MB/s. Our specifications must reach at least 350 MB/s.

Another problem is the size of the design. The GSRD systems occupies the 79% of the Virtex4FX12 (in the ML403 board). The best option is to use the next FPGA, the Virtex4FX20, but the ISE WebPack, don't sinthetize this chip. The cost of the product it's growing up!!

The last option that I'm evaluating is the UltraController II. I have sinthetize the XAPP807 reference design, a Gigabit webserver. The used resources are minimal (two FIFOs, 20 slices and 18 LUTs) but I have several doubts yet. The UltraController II use the PPC405 as the engine to control the temac (Exclusively?). I'm investigating about to expand the design to use the PPC405 for others parrallel issues but the work flow is different like the EDK's flow and there is no access to the PLB or OPB buses.

Maybe the GSRD team can make a smaller gigabit design? I wait that!

 

[Slurp]

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

Falk Salewski wrote:
I am doing some research on the reliability of microcontrollers software
in comparison to hardware description languages for PLDs (CPLD/FPGA).

I expect that the statistics needed to prove anything
will be hard to find.

Another interesting point is whether there are general benefits of one
hardware regarding reliability, e.g. in an automotive environment.

Reliability is a system issue.
The concern is performance degradation with time.
Stressors includes vibration, thermal cycling
power supply variations, and variations of
the sequence and phasing of asynchronous inputs.
Both fpgas and microcontrollers could fail
in the face of any of these.

I read about certification problems if a SRAM based FPGA is programmed
every system start and that Flash or Fuse based systems are preferable.

Certification requirements
one of many system specifications.
Most systems use flash of some sort
to initialize RAM of some sort in the
face of the Stressors listed above.

I also read that CPLDs (Flash) in general are more robust than FPGAs.
Can you confirm/confute this?

You need facts, not opinions to confirm such a statement.

-- Mike Treseler

Not sure what Xilinx have to offer but certainly Altera Cyclone and Stratix
FPGA parts have a built in CRC check which is run continuously via an
internal clock at up to 100MHz. When the FPGA boots it is loaded with
configuration and a configuration CRC calculated externally. The FPGA
continuously calculates a CRC from its internal config RAM contents and if
(never known it) it disagrees with the pre-programmed CRC the chip reboots.
On a Stratix part I am using on a military project the reboot takes <40ms.
The parts when in this configuration are deemed by the military to be as
reliable as a CPLD.

Slurp

 

[Jon Elson]

Falk Salewski wrote:

I am doing some research on the reliability of microcontrollers software in
comparison to hardware description languages for PLDs (CPLD/FPGA).

Another interesting point is whether there are general benefits of one
hardware regarding reliability, e.g. in an automotive environment.



I read about certification problems if a SRAM based FPGA is programmed every
system start and that Flash or Fuse based systems are preferable. I also
read that CPLDs (Flash) in general are more robust than FPGAs.

Can you confirm/confute this?


I know one instance where your last sentence is false. I use both

Xilinx CPLD's
and FPGA's in a particular project, all 5 V parts, so XC95xx and
original Spartan.
After having some devices popped in the field, I dug through all the data at
Xilinx until I found a well-hidden document on the ESD tolerance. I
forget the
exact numbers, but the ESD withstand on the XC95xx CPLD parts was WOEFULLY
low, and half that of the FPGA. As these parts were in parallel on the
same data
bus, field experience pretty much agreed with the comparison, at least.
Some
improvements in the ground bonding has helped, but certain users still blow
out the CPLDs on occasion. I've only had one or two Spartans get blown
in that
whole time.

Jon

 

[radarman]

Where I work, we aren't allowed to directly connect FPGA or CPLD pins
directly to external connectors, save for on-board test points (like
Mictor connectors). Everything goes through external buffers or
registers. Yes, it does add latency, but it does protect
hard-to-replace BGA's from damage.

Of course, I work on military hardware, and reliability is a major
factor. While most things are replaced at LRU (chassis) level, there
are some systems where the customer is allowed to replace individual
boards. Usually, this happens in a customer repair facility, and is
done by military technicians, but still - it pays to go the extra mile.

The other factor is that every board costs so much, that they are
almost never thrown away, and instead reworked. It is much simpler to
replace a buffer chip than a BGA.

It is more expensive, but if you are worried about damaging boards with
ESD or want to hot-slot safely, it's worth it.

BTW - we use SRAM based FPGA's for everything except space
applications. There, we use fusible-link devices from Actel or ASICs. A
typical system will load dynamically over VME or PCI from a host
controller, rather than local configuration memories - but that really
shouldn't be a factor. (we do it to simplify inventory issues where a
board may be sold to different customers)

We do occasionally need a PAL or CPLD to implement something that just
needs to be off-chip. A good example is controlling the PCI/VME based
FPGA configuration process. (specifically, we use them as SVF players)
We generally use flash-based devices for that, since they generally
only need to be updated once - and speed isn't usually a concern.

As far as I can tell, the SRAM FPGA's have been working just fine
across a very wide spectrum of environmental conditions for a long
time. Their reliability is actually quite good.

 

Stephen Williams wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Does anybody know if the Xilinx PCI Express cores from Xilinx can
run w/ Icarus Verilog? I can't seem to get access to an eval copy
to find out for myself. The link to the .tar.gz (and the .zip) seem
dead for me.

Nor can I find out if I can use it with WebPACK or I need the full
ISE to access the actual Verilog. The last full ISE I have is 6.2,
but I can obviously get at WebPACK releases. Does WebPACK have the
CORE generators I'd need?
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFER77GrPt1Sc2b3ikRAinfAJ9oG/ezCM4X3fhgUkTTnMdAJqhD5gCfZ+MH
BlApRFl0pMe8P2x5TCfhnPE=
=/YoG
-----END PGP SIGNATURE-----

"Xilinx provides you with the ability to evaluate the functionality of
PCI Express 1, 4 & 8 Lane Endpoint cores using MTI precompiled
functional simulation models."

You don't get access to the Verilog. And it's unclear if you get the
RTL for the purchased version either. (One didn't for the PCI core.)

You can understand that Xilinx would lock it to their part.

 

[Mike Treseler]

ghelbig@lycos.com wrote:

You don't get access to the Verilog. And it's unclear if you get the
RTL for the purchased version either. (One didn't for the PCI core.)

RTL costs extra.

-- Mike Treseler

 

[Falk Salewski]

Thanks for your reply!We also had problems with CPLDs dying according to
probably to high voltages (lab course with students). We are using Spartan
FPGAs in combination with busswitches as interface circuits now and have no
problems any more.
However, if you are using many I/O lines this additional protection needs
some PCB space... seems like an advantage to microcontrollers. We let
students work with Atmel ATmega16 and none of them died during the last
year. And they did a lot to them...

Regards
Falk

"radarman" <jshamlet@gmail.com> schrieb im Newsbeitrag
news:1145585901.442569.73850@t31g2000cwb.googlegroups.com...

Where I work, we aren't allowed to directly connect FPGA or CPLD pins
directly to external connectors, save for on-board test points (like
Mictor connectors). Everything goes through external buffers or
registers. Yes, it does add latency, but it does protect
hard-to-replace BGA's from damage.

Of course, I work on military hardware, and reliability is a major
factor. While most things are replaced at LRU (chassis) level, there
are some systems where the customer is allowed to replace individual
boards. Usually, this happens in a customer repair facility, and is
done by military technicians, but still - it pays to go the extra mile.

The other factor is that every board costs so much, that they are
almost never thrown away, and instead reworked. It is much simpler to
replace a buffer chip than a BGA.

It is more expensive, but if you are worried about damaging boards with
ESD or want to hot-slot safely, it's worth it.

BTW - we use SRAM based FPGA's for everything except space
applications. There, we use fusible-link devices from Actel or ASICs. A
typical system will load dynamically over VME or PCI from a host
controller, rather than local configuration memories - but that really
shouldn't be a factor. (we do it to simplify inventory issues where a
board may be sold to different customers)

We do occasionally need a PAL or CPLD to implement something that just
needs to be off-chip. A good example is controlling the PCI/VME based
FPGA configuration process. (specifically, we use them as SVF players)
We generally use flash-based devices for that, since they generally
only need to be updated once - and speed isn't usually a concern.

As far as I can tell, the SRAM FPGA's have been working just fine
across a very wide spectrum of environmental conditions for a long
time. Their reliability is actually quite good.

 

[Guru]

David Quińones wrote:

Hello Marco & Vladimir

Unfortunately we need TCP/IP in our products, so we need to use the TCP/IP stack and prefereably without any cost. In the relating thing to the speed of transmission on gigabit ethernet, we have reached more than 900 MB/s with the ML403 development board and a cathegory 6 crossover cable with the GSRD reference system, who use the Treck TCP/IP stack with Jumbo frames. Without Jumbo frames the transmission speed falls to 250 MB/s. Our specifications must reach at least 350 MB/s.

Another problem is the size of the design. The GSRD systems occupies the 79% of the Virtex4FX12 (in the ML403 board). The best option is to use the next FPGA, the Virtex4FX20, but the ISE WebPack, don't sinthetize this chip.. The cost of the product it's growing up!!

The last option that I'm evaluating is the UltraController II. I have sinthetize the XAPP807 reference design, a Gigabit webserver. The used resources are minimal (two FIFOs, 20 slices and 18 LUTs) but I have several doubts yet. The UltraController II use the PPC405 as the engine to control the temac (Exclusively?). I'm investigating about to expand the design to use the PPC405 for others parrallel issues but the work flow is different like the EDK's flow and there is no access to the PLB or OPB buses.

Maybe the GSRD team can make a smaller gigabit design? I wait that!

I would't touch UltraController II if I were you. UCII has a very poor
performance due to tiny FIFO's (about 100Mbit/s according to XAPP807
datasheet), so it won't satisfy your needs.

Cheers, Guru

 

[Arlet]

Fred wrote:

I would like to use a FPGA to create some simple test patterns. One of
which is a circle with a variable diameter. I'm not sure where to start.
Can this be realistically be done in an FPGA using minimal resources?

As long as you only want one circle, this can be done fairly easily.
For each generated pixel, calculate x^2 + y^2, and compare with r^2. If
smaller than r^2, you're inside the circle, otherwise you're outside.

Updating x^2 + y^2 is simple because you can use the previous result:
(x+1)^2 = x^2 + 2x + 1, so it only involves an addition. r^2 can be
supplied as a pre-calculated parameter.

For multiple circles, you can instantiate multiple copies, and mix the
outputs.

 

[John_H]

Fred wrote:

I would like to use a FPGA to create some simple test patterns. One of
which is a circle with a variable diameter. I'm not sure where to start.
Can this be realistically be done in an FPGA using minimal resources?

For a single line, the Y distance from center is known - it's from your
line count - and you know the desired radius so your unknowns are the
leading and trailing edges for either a filled circle or an outline.

X^2+Y^2=R^2 or X = +/-sqrt(r^2-Y^2)

Here you just need to think of the center as 0,0 and make adjustments
accordingly. The calculation only needs to be done once per line rather
than for each generated pixel which means you have a full scan line's
worth of time to do a calculation; serial aritmatic anyone?

If you don't need to ultra-tiny solution, the raw math is pretty simple
in an FPGA with embedded multipliers and a simple square root algorithm.

 

[Ray Andraka]

Fred wrote:

I would like to use a FPGA to create some simple test patterns. One of
which is a circle with a variable diameter. I'm not sure where to start.
Can this be realistically be done in an FPGA using minimal resources?


Yes, it can. In fact, it doesn't take much logic if you think outside

the box a little bit. Google "Bresenham circle" to find Bresenham's
circle drawing algorithm. No need for multiplies and square
roots...this does it with adds and subtracts by taking advantage of the
incremental algorithm for drawing a circle on a raster.

 

[Kolja Sulimma]

Falk Salewski schrieb:

I am doing some research on the reliability of microcontrollers software in
comparison to hardware description languages for PLDs (CPLD/FPGA).

Another interesting point is whether there are general benefits of one
hardware regarding reliability, e.g. in an automotive environment.

This all depends on the type of errors you are talking about. To get an
overall estimate will be really difficult.

E.g. in automotives a big issue are real time constraint violations when
many things happen at once. You can easily specify the timing of most
hardware implemented algorithms with a granularity of nanoseconds
because there is real concurrency in the implementation. For uC it is
hard to get below tens of microseconds.

Also, error detection and correction on ALUs, busses and memory is just
not available for commercial uC, while you can easily implement it for
your FPGA circuit. In theory a uC using all these techniques would be
more reliable, but if you can not buy it....
(BTW: I talked to Bosch about that topic, and apparently the volume of
their orders is not big enough to have Motorola design such a uC for them.)

Formal model checking and property checking are becoming mainstream for
hardware development but are hardly ever used for software development.

These are all factors in favor of FPGAs that are often not considered,
but I am sure that you come up with many reasons why uCs are more
reliable. (Less transistors for example)

Kolja Sulimma

 

[Ben Jones]

Hi Fred,

"Fred" <fred@nowhere.com> wrote in message
news:4448b5a2$0$209$db0fefd9@news.zen.co.uk...

I would like to use a FPGA to create some simple test patterns. One of
which is a circle with a variable diameter. I'm not sure where to start.
Can this be realistically be done in an FPGA using minimal resources?

Circle are in fact very easy to draw (or "scan convert", in the lingo). You
can do it without any square-roots or even multiplies (except by 2). The
algorithm due to Bresenham has been around for some time. Here's a good
tutorial page:

http://www.cs.unc.edu/~mcmillan/comp136/Lecture7/circle.html

The basic algorithm can easily be adapted to do filled circles.

Have a lot of fun,

-Ben-

 

[Thomas Womack]

In article <4448b5a2$0$209$db0fefd9@news.zen.co.uk>,
Fred <fred@nowhere.com> wrote:

I would like to use a FPGA to create some simple test patterns. One of
which is a circle with a variable diameter. I'm not sure where to start.
Can this be realistically be done in an FPGA using minimal resources?

If you already have an X and Y register from your video driver, and a
starting-new-line signal, then you can manage with two adders and a
comparator.

Have a register initialised to cx^2+cy^2 at the start of the frame.

At the start of each line, add 2*(y-cy)+1 to the register.

At every pixel, add 2*(x-cx)+1 to the register.

If the register value is less than a threshold, light the pixel,
otherwise don't.

Tom