EDK : FSL macros defined by Xilinx are wrong

Arthur <arthuryang42spam@yahoo.com> wrote:
: Your design should fit going from the 9500 to the 9500xl. The 9500xl
: actually has more function block fanin (36 to 54!) so I would think
: that there should be no fitting issues.

That's what I hoped, but no luck (so far).

: The loss of wire-anding would cause your PTerm requirements to
: increase. Perhaps if you were near the maximum utilization for this it
: would not fit.

I suspect that is it. The report I get from the failed XC9536XL fit is:

"Mapping a total of 36 equations into 2 function blocks......
ERROR:Cpld:935 - Cannot place signal P<3>. Consider reducing
the collapsing input limit or the product term limit to prevent
the fitter from creating high input and/or high product term
functions".

When successfully put into an XC9536 the report says:

Macrocells used: 36/36 (100%)
Product terms used: 146/180 (81%)
Registers used: 36/36 (100%)
Pins used: 34/34 (100%)
Function block inputs used: 56/72 (77%)

There are lots of signals shown as "wire-AND input".

: You may want to try contacting the Xilinx hotline. They are willing to
: try fitting close designs.

I'll try that.

Richard.
http://www.rtrussell.co.uk/

 

[Yves Deweerdt]

Jay wrote:

Hi all,

I'm doing prototyping for ASICs. Before I start my work, I have to estimate
the gates the FPGA or CPLD would use.
I know it's hard to get a precise result. I just want some common answer,
1:3 between ASIC and FPGA/CPLD gate count?(not consider the memory, just
logic)
Please tell me your experience.

Thanks,
Jay

Hi Jay,

When defining an ASIC gate as a standard 2-port nand gate, the typical
relation between ASIC and FPGA would be 1:10.

Kind regards,

Yves

 

[Peter Ryser]

Hi Jon,

OK cool. What is the status of V2Pro/PPC linux these days from a user
perspective?

As I said privately there is a bunch of patches but not a single source
of a port yet. I am mostly using the public Mind patches with some of my
own code and firmware to tie things together.
The kernel is a stock 2.4.20 as I do not want to use the Mvista tree.

Linux support for Virtex-II Pro is available as part of the LinuxPPC kernel
tree. Access to this tree which is synchronized with the main kernel tree in
regular intervals is available from http://www.penguinppc.org/kernel.shtml.
MontaVista is just one host for the tree. Unfortunately, the code available
in the LinuxPPC repository has not yet been moved into the main kernel tree.

The available port supports Uarts, Ethernet, IIC, interrupt controller, PCI,
GPIO, TFT, touchscreen, PS/2, and System ACE CF. Xilinx is working with
MontaVista to add support for UartLite, SPI, RTC, and Gbit Ethernet.

- Peter

 

[Michelle Lee]

I have the same problem as Rgr and I already did what you said. I imported the updated files back to XPS and used "update bitstream". I tried downloading the program onto the board and it doesn't work. <p>By the way I'm using EDK 5.1i and the ML300 evaluation board. <p>Please help.

 

[Jon Masters]

Peter Ryser wrote:

Jon,

besides what John has produced for uCLinux, Xilinx is working with
MontaVista to integrate UartLite support into the Linux kernel tree for
PowerPC.

Any ideas when this will be available? At the moment I have stuck the
driver John wrote in to 2.4.20 and changed most of the relevent parts.
The plan is to assist debug what he has unless Xilinx and Montavista are
likely to have a driver out within the next week or two.

Jon.

 

[Peter Ryser]

I really hope (we are working on it) that at some point in time Virtex-II Pro will

become part of the main kernel tree. Until then penguinppc is the place to go to
for the open source kernel support for V2P. Alternatively, especially for
commercial purposes, I recommend to contact MontaVista for professional support.

The reason why I suggest to use penguinppc or MontaVista is the tight integration
into EDK. EDK is able to generate a board support package, i.e. layer 0 and 1
drivers, tailored for the use within Linux. Parameters like base address, high
address, optimizations, and available functions for a given peripheral are
automatically copied from the hardware description into the Linux kernel. The same

is true for the latest drivers shipping with EDK which update the sources in the
kernel tree.

- Peter



Jon Masters wrote:

Peter Ryser wrote:

Linux support for Virtex-II Pro is available as part of the LinuxPPC kernel
tree. Access to this tree which is synchronized with the main kernel tree in
regular intervals is available from http://www.penguinppc.org/kernel.shtml.
MontaVista is just one host for the tree.

I know as I have several different (in fact more than several now)
trees. The setup I have is mostly from the Mind patches to the
Montavista tree manually applied to 2.4.20 by me because I prefer the
kernel.org one without all the additional board support I do not need.

Unfortunately, the code available in the LinuxPPC repository has not
yet been moved into the main kernel tree.

I had a discussion with some people recently about that.
The thing is that there are so many different sources for PowerPC Linux.
I use yet another set of patches for my Powerbook which also runs Linux
from the benh tree.

Jon.

 

[Jim Granville]

news@rtrussell.co.uk wrote:

Arthur &lt;arthuryang42spam@yahoo.com&gt; wrote:
: Your design should fit going from the 9500 to the 9500xl. The 9500xl
: actually has more function block fanin (36 to 54!) so I would think
: that there should be no fitting issues.

That's what I hoped, but no luck (so far).

: The loss of wire-anding would cause your PTerm requirements to
: increase. Perhaps if you were near the maximum utilization for this it
: would not fit.

I suspect that is it. The report I get from the failed XC9536XL fit is:

"Mapping a total of 36 equations into 2 function blocks......
ERROR:Cpld:935 - Cannot place signal P&lt;3&gt;. Consider reducing
the collapsing input limit or the product term limit to prevent
the fitter from creating high input and/or high product term
functions".

If the fitter has not at this stage reported the Prod terms, you
could re-target a 9572XL,(just for the purposes of getting
a complete fitter report!), and then compare with the one below.

It's common for fitter reports to be sparse/terse on failure, so
you are sometimes best to use a 'does fit' pathway
- even if that needs some gyrations !

-jg

When successfully put into an XC9536 the report says:

Macrocells used: 36/36 (100%)
Product terms used: 146/180 (81%)
Registers used: 36/36 (100%)
Pins used: 34/34 (100%)
Function block inputs used: 56/72 (77%)

There are lots of signals shown as "wire-AND input".

: You may want to try contacting the Xilinx hotline. They are willing to
: try fitting close designs.

I'll try that.

Richard.
http://www.rtrussell.co.uk/

 

[Peter Ryser]

It sure is! I'm bringing across the PPC kernel drivers into uClinux at
the moment, and there's some funny stuff going on in there! Some wierd
hard-coded assumptions about the names given to OPB peripherals, and
some other crazy things - but the workaround was quite simple.

I'd be interested to hear what the workaround is.

The reason I ask is that if I spend the time to integrate an ethernet
MAC into the microblaze-uclinux hardware target and get the driver in,
can I be reasonably confident that the driver itself works properly, and
that any errors are therefore mine?!

The Ethernet works fine in interrupt driven mode. It doesn't work for SGDMA.

- Peter

 

[Hal Murray]

Vcc bounce is hardly an issue with most designs. That is why it is not often
considered.

Ground bounce affects everything: slicing level, jitter, timing, function of the
device (etc).

Vcc bounce my affect IO output timing, jitter, but is generally a second order
effect.

Thanks.

Why the asymmetry?

I'd expect TTL type inputs (referenced to 2 diodes above ground) to be
sensitive to ground bounce only, but what about others?

I thought the reference for CMOS was roughly 1/2 way between Vcc and
Ground. Wouldn't that wiggle if Vcc wiggled?

Is PECL referenced to Vcc?

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Jim Granville]

Hal Murray wrote:

Vcc bounce is hardly an issue with most designs. That is why it is not often
considered.

Ground bounce affects everything: slicing level, jitter, timing, function of the
device (etc).

Vcc bounce my affect IO output timing, jitter, but is generally a second order
effect.

Thanks.

Why the asymmetry?

I'd expect TTL type inputs (referenced to 2 diodes above ground) to be
sensitive to ground bounce only, but what about others?

I thought the reference for CMOS was roughly 1/2 way between Vcc and
Ground. Wouldn't that wiggle if Vcc wiggled?

Yes. What separates the issue on FPGA and bigger CPLD, is the core Vcc
is
not the same pins as Vcc[io] - whilst bounce on the common GND can
disturb the
core (where it is certainly noticed
Vcc[io] bounce WILL disturb the IO threshold, but most digital signals
pass thru the threshold very quickly.
In a jitter paranoid application, you could expect to notice Vcc
related
crosstalk.

Is PECL referenced to Vcc?

Outputs are emitter followers on open collectors, so yes.
PECL is normally differential, so you get PSR that way, plus you
also reduce any spikes, due to the balance drive.

- jg

 

[Peter Seng]

"Yash Bansal" &lt;yash@viper.ece.ucdavis.edu&gt; schrieb im Newsbeitrag
newsine.HPX.4.21.0307301129160.4735-100000@viper.ece.ucdavis.edu...

On Wed, 30 Jul 2003, Andras Tantos wrote:

I am currently trying to perform a readout from FPGA to a LINUX PC
using
parallel port. I have implemented the state-machine for EPP
communication
in the FPGA and it works well however the system is slow.

I think this is because EPP devices are supposed to negotiate the best
available transfer mode during initialization but the FPGA is not
currently setup to do that. As a result, I had to fall back on
software
emulation of the data transfer handshaking.

I was wondering if anyone has experience performing readout from FPGA
using EPP. My aim is to get 1MByte/sec communication. Any help would
be
appreciated.


I had the same experience: the PC parallel port HW wouldn't switch into
EPP
mode without the proper negotiation. You will stay in SPP mode on the SW
side, though you can emulate the EPP protocoll from SW. And yes, it's
slow.

Andras Tantos

Were you able to implement the proper negotiation and avoid staying in
SPP? If so what do you recommend?

-Yash

Hello Yash,

we reached about 500 Kbytes transfer rate using EPP mode for read or write.
Half rate using PS2 (8-bit bi-dirctional mode) read or write mode and
SPP(standard parallel port, byte out/nibble in) write mode. Quarter rate at
SPP read mode. We used Win2000 and a none PCI based parallel port chip at
the PC side (standard at PC mainboards).
Using a parallel port based on a PCI card, transfer rate could be up to 450
Kbytes using PS2 mode, but implementing EPP mode can be hard (if it ever
works). Seems to be chip dependent, and we didn´t get good support from PCI
chip manufacturer.
Hint: do not set port to ECP or ECP/EPP mode, better set it to EPP mode (via
PC BIOS).

good luck,


Peter Seng


#############################
SENG digitale Systeme GmbH
Im Bruckwasen 35
D 73037 Göppingen
Germany
tel +7161-75245
fax +7161-72965
eMail p.seng@seng.de
net http://www.seng.de
#############################

 

[Erik Coenders]

hmurray@suespammers.org (Hal Murray) wrote in message news:&lt;viofmij2jhd50b@corp.supernews.com&gt;...

As a study for a project I need to investigate the possibility of
implementing a tiny TCP/IP stack and tiny MAC controller on FPGA. This
stack is capable to transfer some data packets directly into S(D)RAM
without help of the microcontroller. Thus a simple communication via
Ethernet from the desktop PC is required for download/upload to/from
the memory.

TCP gets pretty complicated. I expect the best way to do in in an
FPGA would be to build a CPU and treat it as a software problem.

You might try UDP first. A server-only UDP implementation doesn't
need any timers or routing tables. (You can send the packet back
where it came from. Be sure to fixup the broadcast case.)

What do you mean about "Be sure to fixup the broadcast case"?

It is not the intention to implement all TCP/IP functions in the FPGA
(target). As far I had read and understand some stuffs about Ethernet
protocols. The minimum "processor-less" requirements is the UDP
protocol for a simple data transfer without data loss checks. In the
UDP frames a sequence number can be inserted to verify the data
completeness. Checksum calculation and handlers can also be
implemented in the FPGA. No stack is required when all valid UDP
packets will be processed immediately and stored into the SRAM memory.
In this case all TCP functions/stack can be removed. It will lead to
reduce the amount FPGA logic elements substantiatelly.

I am not sure about some things and have some questions:

1. Is only the UDP protocol sufficient to be implemented in FPGA for
simple data transfers to the target (FPGA) from the PC? Do I need also
the ARP or other protocols?
2. Which protocols can I miss when the PC knows the 32-bit IP number
of the target? Is a 48-bit ethernet address required?
3. Suppose that all UDP packets will also be forwarded through the
router(s) to the target. Does it needs a special attention when only
the UDP is implemented? Will the routers change the IP header (and UDP
header) of the UDP packets before they are arrived at target?
4. Is the connection negotiation required between the PC and the
target? Do you think that the PC will always transfer some UDP packets
without restrictions?

 

[Paul Burke]

Beeson Wong wrote:

Hi,

When the host is a 'MEN F0001 Power-PC'
card, I used the provided MENMOM on-board
utility ('PCID') to dump out the PCI
configuration spaces of both cards (PLX9030
and Altera MegaCore). Both gave me expected
results.

When the host is a 'PEP CP302 Intel'. I
used two publicly available utilities: WinDriver
under Windows NT and PLXMon under DOS. Both
utilities did not dump out the expected
configuration space values for Altera/MegaCore
card (e.g. the Vendor ID and Device ID were
OK, but all the BARs were zeros). However, the
configuration space for PLX9030 was OK.

It seems the operating systems (Windows NT
and/or DOS) on the host did not allocate resources
for the Altera/FPGA card.

I have had problems with the PLX PCI9052 and certain versions of the
Compaq EVO series. It appears to be a BIOS problem, they aren't allowing
the PLX chip enough time to load from the EEPROM. At least, that was
PLX's view of the problem (of course, Compaq never replied so I don't
know what theirs is).

If your end system is DOS based, if you poke the correct values to the
registers, it works fine thereafter. I expect you can do it with some
Windows versions too, though not NT, MX etc. But plug and play might
mess things up if any hot plugging happens.

Paul Burke

 

[Andrew Paule]

Hi Jay:

the big thing to get through here is an understanding of what a gate is
- it can be a transistor in some ASIC vendors "speak" (like maxim SiGe),
or a 2 input nands in others (IBM/LSI), or other. Let's say that this
is a 2 input nand case - you need two of these for a simple flop, and
can build logic accordingly - I would guess that you are not starting
with the ASIC and trying to implement it in the CoolRunner, but I may be
wrong, so, what you need to do is compile the thing and look at register
usage and cell usage - I'm not familiar enough with the coolrunner parts
to gauge this, but if you can fit say 8 logic "gates" in one CLB or two
registers - you might come close if you look at the ASIC type. Routing
is another variable - I would guess that you are not going to use more
than 80% of your coolrunner part, and an ASIC will be close to 100%
usable. You could try to judge accordingly, but the best way to do this
is to contact your ASIC vendor (each process is different in terms of
definitions and number of metal layers and "process (3 microns and
down)" and number of transistors/resistors/layout). They will know
better than anyone in a newsgroup. Here, we are shooting in the dark,
and it willl not help you too much in reality.

If you are trying to implpement an ASIC intop a coolrunner part, you
will either need the HDL code or a schematic that was used to generate
the ASIC for just logic considerations, and you should be able to crunch
that through quick and get an idea of the number of cells you will use
in the coolrunner.

Andrew

Jay wrote:

Thanks for your response.

To simplify the case, just suppose that I have a 5k gate array ASIC designs
(general logic for control and interface)to implement to one CPLD(may be
CoolRunnerII)

What's the relationship between the ASIC gate array and CPLD macrocells?

"Andrew Paule" &lt;lsboogy@qwest.net
??????:ynlXa.981$h_3.65136@news.uswest.net...


What kind of gates - If you are running standard cell type ASIC, then
the vendor can give you a good idea. If it's a semi custom, you can
figure about 40 transistors for most standard logic gates and flops, but
you'll have to build your own and steer the currents with the available
resistors.

Are there mapped cells (i.e. cells that are fixed in your target ASIC)?
Are there dedicated I/O flops, are there clock specific mask layers?
You need the architecture of your target ASIC to get a good idea of this
ratio, and the architecture of your FPGA -Actel SX and SXA can get
pretty close to 1:1 for some types of ASICs, old PAL based CPLD
structures are dependent on what they call a gate, most others are in
between somewhere.

Andrew
Jay wrote:



Hi all,

I'm doing prototyping for ASICs. Before I start my work, I have to


estimate


the gates the FPGA or CPLD would use.
I know it's hard to get a precise result. I just want some common answer,
1:3 between ASIC and FPGA/CPLD gate count?(not consider the memory, just
logic)
Please tell me your experience.

Thanks,
Jay

 

[Peter Alfke]

Andrew Paule wrote:

snip&gt;Let's say that this is a 2 input nand case - you need two of these for a simple flop, and can build logic accordingly -

Wow, a flip-flop out of two 2-input NANDs ?
Yes, you can make them into a latch with independenr SET and RESET
(active Low), but you need 2 more gates to make it a D input, and you
double the whole thing to get from a latch to a flip-flop. And then
there is Clock Enable, and perhaps asynchronous CLEAR and/or PRESET,
plus perhaps Clock inversion.
You get all that in FPGA flip-flops "for free".

I agree gate count is silly in FPGAs, but let's not distort the argument
even further.
Peter Alfke, Xilinx

 

[Andrew Paule]

Hi Peter:

I agree 100% (an RS is the most fundamental valid flop) - and for a D
type you do need two more gates.
I guess that the whole premis here is that there is some talk going
around trying to make an FPGA - ASIC conversion "standard", being able
to count the whatevers in an FPGA and relate that to whatever type of
gate the ASIC manufacturer is doing. Until there is an understnding of
the ASIC type being targeted, and the FPGA type being used to proto,
there cannot be any sort of gate counting relationship, but I don't want
to jerk the poor guys chain too hard. I think that he's been assigned
the task, and is trying to learn some fundamentals, albeit in the wrong
frame.

Andrew

Peter Alfke wrote:

Andrew Paule wrote:


snip&gt;Let's say that this is a 2 input nand case - you need two of these for a simple flop, and can build logic accordingly -



Wow, a flip-flop out of two 2-input NANDs ?
Yes, you can make them into a latch with independenr SET and RESET
(active Low), but you need 2 more gates to make it a D input, and you
double the whole thing to get from a latch to a flip-flop. And then
there is Clock Enable, and perhaps asynchronous CLEAR and/or PRESET,
plus perhaps Clock inversion.
You get all that in FPGA flip-flops "for free".

I agree gate count is silly in FPGAs, but let's not distort the argument
even further.
Peter Alfke, Xilinx

 

[Mike Treseler]

Ken Land wrote:

This is a high level question about IP Core business models.
I know about the "free" cores at opencores.org and I know you can pay
someone $15,000.00 to license a USB core.

What I'm looking for are companies that are in the middle whose pricing
competes with dedicated chips.

This is like buying a used car, pricing is negotiable.
Cores are hard to sell and there are lots of sellers
and consultants.

Write a detailed proposal telling exactly what
your are doing and what your willing to pay.
In your case the value to you is about
$10 * 300 * 3 years = $9000.
So maybe offer $4500.
Request a compiled sim model and testbench
to evaluate the core.

Email it out, and you should get some responses.
Deal directly the author or his company
rather than resellers.

If they don't respond, or can't provide
a model and testbench, cross them off the list.
Like you say, you can always call NetChip instead.


-- Mike Treseler

 

[Jim Granville]

news@rtrussell.co.uk wrote:

Jim Granville &lt;jim.granville@designtools.co.nz&gt; wrote:

: If the fitter has not at this stage reported the Prod terms, you
: could re-target a 9572XL,(just for the purposes of getting
: a complete fitter report!), and then compare with the one below.

Good idea. However what I tried instead was disabling my
constraints file (which simply determines the pinout). It still
fails to fit, but this time it does report the counts:

Macrocells used: 36/36 (100%)
Product terms used: 180/180 (100%)
Registers used: 36/36 (100%)
Pins used: 34/34 (100%)
Function block inputs used: 73/108 (67%)

It then reports "Cannot place signal P&lt;4&gt;".

This compares with the successful XC9536 report:

Macrocells used: 36/36 (100%)
Product terms used: 146/180 (81%)
Registers used: 36/36 (100%)
Pins used: 34/34 (100%)
Function block inputs used: 56/72 (77%)

So the number of product terms has gone from 146 on the XC9536
to 180 on the XC9536XL and the number of function block inputs
has gone from 56 to 73.

Does this shed any light ? Is it likely it will ever fit in an
XC9536XL ?

A problem here, is it did not fit, and so you do not know if 180 is
product terms WANTED, or just the ceiling it bumped into.
I can give you the observation 'It's not looking good'
-jg

 

[Jim Wu]

If you write down the truth table, you will see the two equations are not
equivalent.

Jim Wu
jimwu88NOOOOSPAM@yahoo.com

Robert Finch &lt;robfinch@sympatico.ca&gt; wrote in message
news:mCdYa.3083$_a4.616963@news20.bellglobal.com...

Is there any benefit in terms of power consumption or performance in doing
something like the following ?

if (a &amp;&amp; b) a &lt;= 0;

It seems to me it could be re-written as

if (b) a &lt;= 0;

to save some logic.

I think the difference is the 'a' reg would be clocked more often using
the
second line of code, but does it make a difference if the same
(pre-existing) value is written to the register ?

Thanks,
Rob

 

[Peter Alfke]

The classical, so-called SRAM-based FPGAs implement logic in 4-input
Look-Up Tables, each with one output, implementing any function of those
four inputs. AND and OR are just more primitive ways of expressing logic
functionality. That's also why Karnaugh maps have become meaningless. If
you can express it as a function of four variables, there is nothing
more to do or to be optimized: It fits in one LUT.

Peter Alfke
==========
Neil Zanella wrote:

Hello,

In view of the fact that most field programmable gate arrays are designed to
accomodate two-level AND-OR expressions how can an FPGA synthesizer benefit
from computing both a minimal AND-OR expression and a minimal OR-AND
expression and then choosing the one of lower cost?

Thanks,

Neil